[0.90] Custom Biomes 1.7.0 [17 Dec]

[NathanKell]

Great! Thank you so much. Will do.

[KerbMav]

feature idea: is it possible to alter the biome map, like an animated gif? or switch between various similar biome maps.

reason for that: if it is possible to do that, planets could have seasons. research could be done through various seasons, and not once per location

Now get someone to integrate your idea into FAR and SCANsat for variable weather effects!

[CaptainKipard]

Were these biomes made in Paint or are they based on the actual terrains?

[Trueborn]

They were based off SCANSAT maps for each of the bodies, overlaid in GIMP. I don't guarantee that the boundaries will match up perfectly with all the terrain everywhere, but if you notice glaring errors let me know so I can fix them.

[Raven.]

Trueborn, I have a question for you if you don't mind. I don't think this is possible, but I am curious as to the size of the biome maps. Is it possible to have higher resolution biome maps? Or is the 1024x512 resolution a limitation set by KSP itself?

[Trueborn]

I haven't done any experiments with higher rest maps, so I can't say for sure. But you're welcome to try scaling one of the maps up and seeing what happens For most of the smaller bodies I think the 1024 rest is plenty, but I could see a higher rest map being used on some of the more complex planets.

[Kowal04]

I'm getting some work done

http://imgur.com/SESAXbe.png

Who knows what might be hidden in that detail........

I should have everything done and in a zip by monday

So unfortunate it was abandoned. I would love to see this incorporated into the game.

[Raven.]

So unfortunate it was abandoned. I would love to see this incorporated into the game.

What planet/moon is this? I think that map may be in the Custom Biomes 1.5 download.

I haven't done any experiments with higher rest maps, so I can't say for sure. But you're welcome to try scaling one of the maps up and seeing what happens For most of the smaller bodies I think the 1024 rest is plenty, but I could see a higher rest map being used on some of the more complex planets.

I'll probably give it a try if you don't mind me messing around with the source. I noticed you had it hard coded in the source, and was wondering if that could be changed.

I you're right, for smaller planets and moons such as Minmus, 1024x512 is more than fine. But for Kerbin, Eve, and Duna, I think it needs 2048x1024.

[Kowal04]

What planet/moon is this? I think that map may be in the Custom Biomes 1.5 download.

It is Duna. You can find it in second page of this thread.

[Raven.]

It is Duna. You can find it in second page of this thread.

Ok, sometime this summer I will be tackling Duna, as I've been asked by a few people to do a biome map for that particular planet. But I cannot tackle it until I'm finished with my current Kerbin project. In the meantime, Trueborn has a basic biome map for Duna in the main download that should hold you over until then.

[Trueborn]

If you get some good utility out of larger biome maps, I'll change the code to just look for aspect ratio instead.

[SpacedInvader]

And as suggested, I have released version 1.5

Spaceport Download

For users, there won't be much of a change except that you can expect to see more customized Science results from across the Kerbol system. At least on Bop, Dres, Duna, Eeloo, and Eve. Eventually I'll do more (and spell check it), but just those five planets is almost 500 lines. The way I'm putting these into the game is a little odd, so there is a good chance there will be an error or two. Please let me know so I can track them down.

For those of you interested in building your own custom biomes, there are a few more changes.

First, is the addition of a ScienceResults.txt file in the biome directory. This is where I'm putting all of the science results that get input with the new biomes. The format is pretty simple. The file is divided up by experiment, with the lead being a line:

id = ExperimentID

This is then followed by a number of lines for specific biomes. These use the same format as the ScienceDefs file, which is Body Name, SrfLanded or SrfSplashed, and then the Biome Name. The next id line or end of the file automatically terminates each experiment.

The second change is to the attribute files. The first line of each attribute file is now checked to see if the exact search feature is used or not. If the line is 0, exact search is not used. All of my biomes are currently set to 0. You can set your own value, which is read as a float. This enables exact search and sets the threshold to the provided value. None of squad's biomes use a value, so I can't recommend a good one. If you find something that works well, let us know!

If there is anything else you have questions about, please let me know.

Alternate Download

Source code.

I know I'm quoting something quite old here, but I've got a question that doesn't seem to have been addressed at all, namely, what exactly does the search threshold value do? From reading, I get the impression that if you set it to zero, you get a return of the exact biome you're currently sitting over but what changes if you adjust this number to some other value? Is there a possibility this could get rid of random biomes showing up where they aren't supposed to?

[Trueborn]

We've done a little research on it, but it doesn't seem like it was fully implemented by Squad. None of the stock biomes use it. You're free to play around with different values yourself (it is the first line in each biome file), and if you get good results let me know.

[SpacedInvader]

Out of curiosity, how much does increasing the number of biomes increase memory usage, if at all? I'm working on a fairly complex biome map for the RSS Moon, and I'm having to fight to get myself under 60 biomes...

[Raven.]

I know I'm quoting something quite old here, but I've got a question that doesn't seem to have been addressed at all, namely, what exactly does the search threshold value do? From reading, I get the impression that if you set it to zero, you get a return of the exact biome you're currently sitting over but what changes if you adjust this number to some other value? Is there a possibility this could get rid of random biomes showing up where they aren't supposed to?

I'm gonna repost this below to help the question.

Ok, last night I did some rather intensive testing with Custom Biomes 1.5 with a biome map that incorporated 20+ biomes for Kerbin. I found some interesting things out.

Me personally, I do not think that the ExactMatch variable does what we were thinking it does. Even with the variable enabled, it still attempts to smooth the transition between biomes. However, instead of every biome with in-between RGB values being reported as the player is transitioning from one biome to the next, it instead reports the first biome in the .att file during the transfer. Basically the current RGB values are still making a smooth transfer between different regions on the map, but the game does not report the current biome unless the RGB values match exactly with a defined biome in the att file. If the RGB values do not match, the game reports the first biome defined in the att file. With ExactMatch disabled, if the RGB values do not match, the game rounds to the nearest defined biome.

The ExactMatchThreshold value does not seem to have any effect on the biomes and biomes detection method. In fact, it seems to be a pure boolean value; if the value is zero, then ExactMatch is false, if the value is something other than zero, then ExactMatch is true.

The ExactMatch variable does have a lot of usefulness, just not in the way we were expecting. For example the first biome listed in an att file can be a "Transitioning" biome, or a "Middle of Nowhere" biome with zero science value. That way the player is aware that the game is transitioning from one biome to the next, and won't automatically report the transition as a bug. Basically the first biome listed is the default biome when ExactMatch is enabled.

In my own personal experience of working with biomes thus far, it my personal recommendation that ExactMatch be enabled (with threshold set to 1.0) for biome maps that have biomes that are generally very large in surface area, and that a default biome be defined as the first biome for that particular biome map. ExactMatch should be turned off for maps that contain biomes that are very small in surface area, as the game has a hard time picking up small biomes when ExactMatch is enabled for some odd reason. The threshold value does not appear to matter. I also strongly recommend that as part of a biome map's design, that special attention is paid to contrast and what colors are being used. Choosing colors that are close to each other in RGB values directly next to each other (low contrast) will minimize the transitioning effects where as much higher contrast will cause transitioning issues. I've noticed that a difference of ten is recognizable by the game, where as with smaller value differences the game gets confused. For example, the game will recognize the difference between two biomes with values 255, 255, 255 and 245, 255, 255. But the game will get confused with values 255, 255, 255 and 250, 255, 255 unless ExactMatch is enabled.

I hope this helps with anyone wanting to develop biome maps. Also, special thanks to Trueborn for creating this resource and for implementing the ExactMatch feature, as my current project would not be possible otherwise .

Out of curiosity, how much does increasing the number of biomes increase memory usage, if at all? I'm working on a fairly complex biome map for the RSS Moon, and I'm having to fight to get myself under 60 biomes...

It does not increase memory usage, at least none that I've been able to detect. If it does, then it's so small that it doesn't register in Windows 7's resource manager. I believe the memory usage would be from the size of the biome map itself.

Edited May 12, 2014 by Raven.

[Trueborn]

The only way you should notice a memory increase is in using larger textures for the biomes maps. The definitions themselves are a string and a couple of floats, so pretty tiny.

[SpacedInvader]

Thanks for the input so far.. Now I've got my Moon map working in game, but it's stuck on the old Mun biome names. Is there a way to rename or omit the old names so I can use all of my own new names? Doesn't seem like anyone has mentioned this up until now (and yes, I searched)...

EDIT: Nevermind... stupid formatting error was stupid... I included the ExactMatchThreshold value for each entry instead of just one for the whole file, fixing that fixed the incorrectly displayed names.

Edited May 13, 2014 by SpacedInvader

[SpacedInvader]

Ok so I could use a little help / input...

This is my mostly completed map of the Moon:

The problem I'm running into is color selection to ensure crossing boundaries doesn't make the biomes jump all over the place. As is, there are only a few places where transitions don't cause jumping biomes, so I definitely need to do something about it. Any input would be helpful. Also, I tried ExactMatchThreshold at 1 and created a transition biome, only to have that pretty much be the only biome ever reported...

Edited May 15, 2014 by SpacedInvader

[Trueborn]

My suggestion is to increase the contrast between neighboring biomes as much as possible. Instead of going from light purple to medium purple to dark purple, go from light purple to yellow to dark purple, etc. That should help with mis-reporting the biomes. I'm not sure if compression impacts the transitions at all, but that's something else to consider.

[SpacedInvader]

My suggestion is to increase the contrast between neighboring biomes as much as possible. Instead of going from light purple to medium purple to dark purple, go from light purple to yellow to dark purple, etc. That should help with mis-reporting the biomes. I'm not sure if compression impacts the transitions at all, but that's something else to consider.

The issue isn't so much that its not detecting the change, but rather that it's detecting other biomes as it smooths the transition. For example, when I go from the yellow to the red, it detects orange and delivers that biome. I will try what you suggest, but I'm concerned that I'm going to end up having to spend a lot of time creating a color list where no two bordering biomes create a color similar to another biome.

Also, PNG compression is lossless, so I don't think that plays a factor here. What I would like to know if there is a way to use a larger map for this. It may help get better definition between biomes if there are fewer transition pixels to deal with.

[Thrust]

I think that to avoid biomes jumping the image needs to be "pixel sharp". Every pixel must be in one of the colors from the list (.att).

Look at this:

Left is too blurry.

[NathanKell]

Also, the fact that PNG is lossless doesn't matter; KSP converts loaded textures to DXT1 (if RGB) or DXT5 (if RGBA). Since DXT5 uses the same compression for RGB as DXT1, we'll just talk about that. DXT1 is lossy, and is only 16-bit color (5+6+5 bits), so there's even more reason to be sure spatial neighbors aren't color neighbors.

[Raven.]

The issue isn't so much that its not detecting the change, but rather that it's detecting other biomes as it smooths the transition. For example, when I go from the yellow to the red, it detects orange and delivers that biome. I will try what you suggest, but I'm concerned that I'm going to end up having to spend a lot of time creating a color list where no two bordering biomes create a color similar to another biome.

Also, PNG compression is lossless, so I don't think that plays a factor here. What I would like to know if there is a way to use a larger map for this. It may help get better definition between biomes if there are fewer transition pixels to deal with.

One thing on my to-do list is to modify the code to see if a higher resolution biome map can be used. I do not know if it's possible or not, but it's worth a shot.

Also, the fact that PNG is lossless doesn't matter; KSP converts loaded textures to DXT1 (if RGB) or DXT5 (if RGBA). Since DXT5 uses the same compression for RGB as DXT1, we'll just talk about that. DXT1 is lossy, and is only 16-bit color (5+6+5 bits), so there's even more reason to be sure spatial neighbors aren't color neighbors.

That explains some things I've noticed with the biome maps, such as the game getting confused with RGB value differences that are less than 10 for example.

[SpacedInvader]

I think that to avoid biomes jumping the image needs to be "pixel sharp". Every pixel must be in one of the colors from the list (.att).

Look at this:

http://i.imgur.com/cKUZncp.jpg

Left is too blurry.

This is one thing I figured out for myself. The fuzziness of my image is a direct result of the source data being at least 20x larger than the final 1024x512 image. I had been using photoshop default bicubic resampling when I shrunk the working image down to the final size, which resulted in all those soft edges. I've since gone back and used nearest-neighbor which preserves hard edges, though it still leaves quite a few pixels that need to be made solid. Its something that I'm going to have to figure out how to automate if I want to keep using large scale, real data.

Also, the fact that PNG is lossless doesn't matter; KSP converts loaded textures to DXT1 (if RGB) or DXT5 (if RGBA). Since DXT5 uses the same compression for RGB as DXT1, we'll just talk about that. DXT1 is lossy, and is only 16-bit color (5+6+5 bits), so there's even more reason to be sure spatial neighbors aren't color neighbors.

I'll really have to look into the colors that I'm using then, as I'm pretty sure some of them are 32-bit. After I've cleaned up the edges through the above method, the map is a lot more accurate, but there are still some issues. For example, when I try to use ExactMatchThreshold, certain areas still only return the transition biome rather than the correct biome, though most of the others work much better now. I'm currently trying to find a more efficient way of distributing colors so that mixed colors are kept to a minimum... I feel like this might be easily done with a script, but sadly my coding skills are quite rusty these days.

One thing on my to-do list is to modify the code to see if a higher resolution biome map can be used. I do not know if it's possible or not, but it's worth a shot.

That explains some things I've noticed with the biome maps, such as the game getting confused with RGB value differences that are less than 10 for example.

Having a higher resolution probably won't get rid of transition biomes, but I really think that it would make them pass much quicker. As always though, the issue of memory will start to grow pretty quickly.

The question I have right now, is might it not just be a better approach to have all of the colors be variations on that same hue with different saturation / value settings? I've got 21 biomes (22 if you include the transition zone), which means that even with at least 10 points difference between each, there should be room to spare on the spectrum. This would get rid of the issues with two neighboring colors combining to make a third, at least for most circumstances, though it will probably get confused still if a lighter and darker neighboring set result in a value that is similar to another found on the map...

EDIT: I can confirm that I've been working in 16-bit only mode the whole time, so I guess that's not necessarily a big issue, though I wouldn't 100% rule it out.

Edited May 18, 2014 by SpacedInvader

[SpacedInvader]

So, a little bit of an update...

After some playing with colors and testing, I've found that the absolute best detection between two biomes is when the colors used are as close as possible on the color wheel.

Here is the most recent color map:

Now, if you look right in the middle of the map, there is a circular area in yellow-green, which is a lowland crater in my list, and then inside of it is another region of green with a little less yellow, which is a lunar lake feature. According to the theory the you need high contrast, KSP should have a lot of difficulty detecting the difference between the two biomes, but this is actually the opposite of whats happening. No matter what variation I try, the fewer color options that exist between neighboring features, the more likely that the game will detect a direct transition from one biome to another. This is further supported by the fact that in areas of high contrast such as going from bright pink to yellow or bright green to orange, the game often reports some intermediary biome(s) before settling on the new biome.

When I get home tonight, I'll altering the map to keep all of the neighboring biome colors as close as possible to see if that solves the issues. That being said, if it works, it would be great for in-game use, but much more difficult to use as an out of game reference...

EDIT: Assuming this pans out, it brings up the question of how hard it would be to expand custom biomes to allow for two maps instead of one. The first would be the one the game uses to figure out where you are, while the second would be the one displayed to the user so they could easily figure out what biome was where...

Edited May 19, 2014 by SpacedInvader