Normalising terrain height values

[impaktor]

I'm really looking forward to any progress done here.

Exciting stuff.

BTW, from youtube videos done in 2010 it looks like pioneer terrain was more varied than its current state? Or maybe the video maker specifically chose planets with unusual sharp ravines and mountains.

[FluffyFreak]

Got a link to the video?

[impaktor]

This could just be an effect of me always playing on the lowest graphical settings, and not doing any planet exploration at all, but I was thinking about mountain rich terrain as seen here:
https://www.youtube.com/watch?v=CZJs-NHTi3k&t=3m40s
https://www.youtube.com/watch?v=CZJs-NHTi3k&t=6m2s

[FluffyFreak]

Some of those do look good :)
There's been so many changes over the years that it's hard to know for sure but in general I think that the planets are smoother nowadays with less super-mountains like that.
Mostly this is because whilst you can tune noise based systems to sometimes, even mostly, produce interesting things like that, you also get lots of instances where the randomness of it causes massive bugs.
We still have a few small spike-ball planets that you cannot land on at all due to the terrain looking like an angry sea-urchin (http://4photos.net/photosv3/Cool_photo_ ... 673029.jpg).
I'm betting that in fixing some of those planets the terrain has gotten a lot flatter.

I've done almost nothing with the height generation side (yet) as that used to be a guy called s20dan and a few others chipping in with bits n' pieces. I've mostly just done rendering optimisations, memory usage reduction, multi-threading and some other bits.

[FluffyFreak]

Just going through trying to figure out how we determine the radius of a planet and I notice that in StarSystem.cpp we just do something like:

m_radius = fixed::CubeRootOf(m_mass);

For most planets with a couple of caveats, but that's the basic case.

What I'm wondering is if we can determine in advance the maximum height of the terrain based on the planets radius, mass, density and atmosphere.
Then instead of getting values out of the terrain generator which are very small, we can just use the 32-bit float range from 0 to 1 and multiply then up to the final height values as determined using radius/mass/density/etc.

Does anyone know of any literature describing something like this?

[FluffyFreak]

Been thinking about this some more and trying to do some reading about the factors behind it, it seems however that my Google-fu is weak (also my brain is just damned tired) and I can't find much with actual descriptions or maths involved.

What I have found is a lot of handwavium style discussions about things like why Olympus Mons (Mars) is so big. It's often discussed that it's size is not just a factor of gravity, it's a lack of plate tectonics too.
The hot-spot which produced it simply wasn't moving around underneath and so always poured it's contents out in a single place creating the solar systems biggest volcano!

So any definition of the maximum height of the terrain for a body must take into account the gravity, it's volcanicity and whether or not there are plate tectonics involved.

Do all worlds have plate tectonics?
Or are plate tectonics a feature of all worlds but only during a certain length of time?
For example a young recently formed world might have plate tectonics but lose them rapidly due to being small and not able to retain it's heat whilst far away from the Sun (like Mars) but what if Mars was nearer the Sun like Mercury or Venus? Would the window last longer? Long enough to disrupt the formation of a super-volcano like Olympus Mons and thus reduce the maximum feature size?

Also will this mean that two worlds will need different world-generator properties to handle the fact that one will have ridges, plate collision mountain ranges and subduction zones due to it's active plate tectonics but another might have a super-volcano sticking up and out of it's atmosphere but otherwise lack features distinctive of an Earth-like world? Take the Himalayas, they used to the sea-bed, you can find fossilised sea life right at the top of Mt Everest and it's made of shale and limestone, that's only possible on a world with plate tectonics. Or the Alps or Rocky mountians etc, they're all features feature driven by plate tectonics, limited in height by gravity and erosion.

More rambling another day, I'm taking the weekend off :)

[FluffyFreak]

More rambling another day, I'm taking the weekend off :)

Wow, long weekend I took there given that it's now 16th September 2015

Well here's some updated and Textured Terrain to wet your appetites.

Things to do... many:

• Determine the max terrain height, approximately anyway.
• Fix the water and lava rendering.
• Improve the input data used to lookup the texture.
• Get some better textures!
• Make a better lookup texture!
• Document it all.

Getting closer though - as usual code etc is on a public branch terrain-texture-arrays and a WIP PR will come along soon.

Andy

[bszlrd]

Great!

What's a lookup texture?
How many kind of better textures will be needed?

[FluffyFreak]

The lookup is used to pick out textures from the array - NB: some of these images are for illustration, they aren't quite like this in the PR or in memory.

The array looks something like this:

This is just for example, it's actually 16 DDS textures on disk, each with their own mipmaps that are loaded and stored separately before being put into a texture array in memory.

And the lookup table currently looks something like this:


The lookup table itself is accessed based on two factors like this:

Slope is the angle of the terrain with the value getting larger the steeper that the terrain is.
Height is going to be sort of normalised to a range, I'm not 100% sure how this will work yet, it's still evolving in my head but you can think of it running from sea-level to a little bit beneath the height of the tallest peak.

The values used in the lookup are chosen so that if you wanted to access the 7th image in the array you multiply 7 by 16 to get 112 which is the shade of red you then store in the lookup so the full range of shades of red are as follows:
0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 240

Note that the values start at 0 and go to 240.
256 invalid, it will work, but I'll just clamp it to 240 (i.e 15) in the shader.

So, in the shader I take the slope and height values and read a value from the lookup texture.
For "computer graphics" reasons this will be in the range 0..1 so I then multiply it by 16 to get the index into the array. Obviously 0 = 0, 0.5 = 8, 1 = 16 etc etc etc.
Now I use this value to read the chosen texture in the array, that texture will then match whatever was chosen to be snow, ice, grass, water, rock, sand ... upto 16 choices of textures basically.

Does that explanation help?

[bszlrd]

I think yes, but I need to wrap my head around that lookup texture. So there will be 16 shades of red, and they point to one of the textures, and I put these shades on that lookup, like if it was a graf, a combination of height and slope. Am I reading it correctly?
I'd guess there will be a blending between the textures in the final result, right?