[0.90] Custom Biomes 1.7.0 [17 Dec]

[SpacedInvader]

Ok, so it seems my theory pans out at least to a degree...

Newest test map:

I went through the whole list of biome layers giving them colors equaling 10° of hue seperation and 100% saturation and value. The game was easily able to differentiate between color differences that were so minute that my eye could only just barely register them at high zooms (e.g. the polar regions and polar craters). The failure arises when a border exists where an intermediate color exists somewhere else on the map. It would seem that the trick is not to increase the contrast as much as possible which is likely to increase errors by introducing a lot of intermediate colors, but to absolutely minimize the number of biome border crossings which have the possibility of intermediate colors.

Edited May 19, 2014 by SpacedInvader

[Trueborn]

That's pretty impressive work SpacedInvader. I might have to take a look at changing some biome colors, too. Have you tried the low contrast map without ExactMatch yet?

As far as the two map option, I would like to reiterate that my intent for having the maps is more so that users can see which biomes are loaded rather than as a significant mapping option. I would still recommend something like SCANsat for actually looking at and locating biomes.

[SpacedInvader]

That's pretty impressive work SpacedInvader. I might have to take a look at changing some biome colors, too. Have you tried the low contrast map without ExactMatch yet?

As far as the two map option, I would like to reiterate that my intent for having the maps is more so that users can see which biomes are loaded rather than as a significant mapping option. I would still recommend something like SCANsat for actually looking at and locating biomes.

I have, but with so many colors, it is difficult to work. Basically it goes like this:

Going from colors A -> B or C -> D where A,B, C, and D are all adjacent on the wheel (Green, Yellow-Green, Yellow, Yellow-Orange) will always return correct results without exact match threshold. The problem is the game will almost always recognize the intermediate colors if they exist, so going from A -> C will produce B along the way. Where it seems to get uncertain is when there are other options, in this case going from A -> D. This seems to be because it could either go through B and C, reporting both, or it could go the other way around and simply report A -> D. So far in my experience there is a 75% percent chance it will go whichever way is closer on the wheel, so in this case it would report B and C more likely than it would omit them.

Based on this, my recommendation would be that you can avoid using exact match threshold, even on a map with a lot of biomes, if you can ensure that there aren't ever intermediate colors between neighboring biome colors. Something like an elevation map would work well, as neighboring biomes vary rarely jump multiple colors. On the other hand, even with low contrast, if you can't ensure that each border only has one possible combination, then the game WILL always report the intermediate color, even if only for a moment. In this case it's best to use exact match threshold as it will save you all of the brain-damage of trying to minimize the number of color variations.

This being said, the fatal flaw, both standard biome reporting and that with exact match threshold, seems to be that it has a low sampling resolution which doesn't vary by altitude. For standard reporting, it means that the area where you would actually get mixed colors is larger than it really should be. For exact match threshold, this means that if an area has enough variation over a short distance, it will never read anything other than the first biome on the list (i.e. the transition biome). Basically, my thinking is that the game detects a 4x4 (at least, though my gut is telling me its larger) pixel square and reports the nearest match to the average color of that square. When crossing biomes that don't have intermediate colors between them, it simply switches to the next biome when more than 50% of those pixels match the new biome color. However, when crossing a border with several intermediate colors, the game with see one or more of them in the resulting average and report them. With exact match threshold enabled, it removes the ability to report anything but the first biome on the list unless all of the pixels in the search box are the same color. To be perfectly honest, the best possible way to enhance reporting accuracy would be to shrink the search box somehow, maybe even down to a single pixel, so that there would be no averaging of colors, though I'm guessing there is a reason they didn't do this in the first place...

[NathanKell]

Might be worth looking into the math of DXT1, how the compression actually works.

[SpacedInvader]

Might be worth looking into the math of DXT1, how the compression actually works.

Ugh... math....

That being said, the 4x4 lookup table may be a factor, but I'm not sure how much here. I don't think the DXT format averages anything in the output, which is what the game should be using. Maybe as a math type you can give your opinion on this Nathan? I still really think this is a raster math function that is using too large of an input window for some reason.

[Xiong]

Running KSP 0.23.0 (64-bit version for Linux) with CB 1.5; a career with 'Basic' map set does not load any of the custom biome maps at all; they are visible neither with ScanSat nor directly through the CB toolbar-button window (which itself works fine). The 'Basic' set clearly is set; the three stock bodies' maps display in living color. All other bodies display a little tab with the text, No map for X.

Here's a few lines from KSP.log:

[LOG 00:07:50.285] AddonLoader: Instantiating addon 'CustomBiomes' from assembly 'CustomBiomes'

[LOG 00:07:50.287] Starting Custom Biomes v1.5

[LOG 00:07:50.304] Parsing rect

[LOG 00:07:50.304] Parsing bool

[LOG 00:07:50.304] Parsing rect

[LOG 00:07:50.304] Parsing bool

[LOG 00:07:50.305] Parsing int

[LOG 00:07:50.305] Parsing string

[LOG 00:07:50.325] Biome replacement complete.

I have a lot of mods installed but none I think *should* conflict. If I can put together a few hours, I'll see if I can eliminate possible causes.

[Xiong]

Well that was quick. With nothing at all installed in GameData except CustomBiomes, Squad, and 000_Toolbar; same as before. I sent a command pod to the pad, opened the Toolbar and added the CB button; clicked the button, checked that 'Basic' was set for the new Sandbox, and clicked to Moho. "There is no biome map for Moho." -- or for anything except the three stock bodies.

As before:

[LOG 04:34:19.528] AddonLoader: Instantiating addon 'CustomBiomes' from assembly 'CustomBiomes'

[LOG 04:34:19.535] Starting Custom Biomes v1.5

[LOG 04:34:19.573] Parsing rect

[LOG 04:34:19.573] Parsing bool

[LOG 04:34:19.573] Parsing rect

[LOG 04:34:19.573] Parsing bool

[LOG 04:34:19.573] Parsing int

[LOG 04:34:19.573] Parsing string

[LOG 04:34:19.610] Biome replacement complete.

As before, KSP.x86_64 (patched as usual), CB 1.5. The biome files are there but they do not load.

[Xiong]

The above issue with biome maps failing to load is corrected by first cd to the dir enclosing the game executable. (Thanks, taniwha.) Suggest checking your pathfinding code.

[Trueborn]

Sorry I didn't see this earlier, I was enjoying the long weekend. Might I ask what directory structure you are using? I guess I'm not sure where you are CD-ing, and when.

[Miximix]

Ok, so it seems my theory pans out at least to a degree...

Newest test map:

http://i.imgur.com/LOMgINp.png

I went through the whole list of biome layers giving them colors equaling 10° of hue seperation and 100% saturation and value. The game was easily able to differentiate between color differences that were so minute that my eye could only just barely register them at high zooms (e.g. the polar regions and polar craters). The failure arises when a border exists where an intermediate color exists somewhere else on the map. It would seem that the trick is not to increase the contrast as much as possible which is likely to increase errors by introducing a lot of intermediate colors, but to absolutely minimize the number of biome border crossings which have the possibility of intermediate colors.

Looks very nice! But where can i get .att file for that?

[Ryusho]

Good thing the alternate download was here, I was going to get it and only learned now spaceport is shut down, and well, this doesn't have a link if it is on Curseforge.

[Trueborn]

I haven't moved my stuff to Curse yet. I'll probably do it with the .24 release.

[dtoxic]

hi...a question

does custom biomes work with other (science) mod's (fasa aies l-tech etc) or is it just for stock science parts?

thx

[albany_]

It'll work for other science mods. They probably won't have biome-specific results, but they will grant science.

[dtoxic]

It'll work for other science mods. They probably won't have biome-specific results, but they will grant science.

ok thank you

[Hotblack Desiato]

nice mod, a friend of mine and I use it in our standard ksp installation.

is there a way that planet factory modder can add biome-maps for their added planets?

because I'm thinking about adding a few planets to my installation, and it would be nice, if they have additional biomes (and it should be quite easy to add biomes for those modders, since they have access to the height-map files and the textures).

regarding the biome-borders: how about this:

each biome has its own color-value, but they differ just by one step. this way, there aren't any intermediate colors possible.

for the biome map, there is some sort of shader, which enhances the differences, or displays just a second map with the same borders.

[Schmonzo]

so am I correct in assuming that this works in 23.5?

[Trueborn]

so am I correct in assuming that this works in 23.5?

I has not been compiled against 23.5, but it does function. Expect a new version when 0.24 releases.

And Hotblack, see the first page of this post for how to create your own biomes.

[Tyrador]

Sorry, but how do I disable the map GUI? In config file there is no DisableGUI property.

[Trueborn]

The property in the config file is GUIEnabled:

<bool name="GUIEnabled">1</bool>

Change the 1 to a 0, and you shouldn't see the button anymore. Alternately, you can hide the button within toolbar itself.

[jandcando]

Ok, so it seems my theory pans out at least to a degree...

Newest test map:

http://i.imgur.com/LOMgINp.png

I went through the whole list of biome layers giving them colors equaling 10° of hue seperation and 100% saturation and value. The game was easily able to differentiate between color differences that were so minute that my eye could only just barely register them at high zooms (e.g. the polar regions and polar craters). The failure arises when a border exists where an intermediate color exists somewhere else on the map. It would seem that the trick is not to increase the contrast as much as possible which is likely to increase errors by introducing a lot of intermediate colors, but to absolutely minimize the number of biome border crossings which have the possibility of intermediate colors.

Where can I get a .att file for this? Do I have to make one myself, or is there one you can point me to?

[Trueborn]

I don't think he's released it yet. You could try sending him a PM. I don't have it though.

[Trueborn]

FYI, Custom Biomes will automatically disable itself when running under 0.24. I'm doing some testing tonight, and if it works without any changes I'll release a new version tonight or tomorrow.

[Trueborn]

Custom Biomes 1.6 is now available for download. This is a simple re-compile for 0.24x64, and the new version of compatibility checker. Toolbar is still required, but not included in this download. I haven't noticed any problems with 0.24, but haven't had time to extensively test. Please report any issues you find! Thanks.

[aftokinito]

Custom Biomes 1.6 is now available for download. This is a simple re-compile for 0.24x64, and the new version of compatibility checker. Toolbar is still required, but not included in this download. I haven't noticed any problems with 0.24, but haven't had time to extensively test. Please report any issues you find! Thanks.

Toolbar is indeed included on the download, not sure what version though.