0
\$\begingroup\$

I am currently experimenting with rendering planetary scale terrain.

I am generating the terrain on the GPU with noise, and to fix the 32 bit floating point precision problems, I generate the heightmaps that need the most precision (the deepest levels of the quadtree I am using for the level of detail) by bicubically interpolating the heightmaps generated for the parent heightmaps (that are generated with normal 32 bit floats, since they don't need a lot of precision).

Doing it this way limits the amount of details the terrain can have, because the smallest details are generated with 32 bit floats, and if more detail is needed, bicubic interpolation is used to generate the intermediate height values.

The issues with this is that if I want extremely detailed terrain, 32 bit float textures (I store the heightmaps in those) are not precise enough, resulting in terraced terrain.

Is there a way I can store more distinct values inside a texture?

Thanks.

Improve this question
\$\endgroup\$
  • 2
    \$\begingroup\$ We had another question about generating planetary-scale terrain a little while back. The recommendation there noted that just because your heightmaps as a full collection span planetary scales, any one individual heightmap does not. A 32 bit float can cover a range of heights from the bottom of the Mariana trench to the top of Mt Everest with better than millimeter precision, so bracketing your working space to this range should get you what you need without resorting to more exotic storage formats. \$\endgroup\$ – DMGregory♦ Jan 30 '20 at 1:58
  • \$\begingroup\$ Wait, you can store that many values in a float? Hmm, I was getting terraces when generating terrain for really deep quadtree nodes, so maybe I'm just in the "waaayyy less than millimeter precision" scale and didn't realize it. Thanks :) \$\endgroup\$ – Raouf Jan 30 '20 at 2:22
  • 1
    \$\begingroup\$ I have a table of what precision range you can expect from single-precision floats in this answer. What you describe is pretty typical of working with floats: they're an easy point in the pipeline to blame for our inaccuracy, but more often the problem is modelling error - inaccuracies compounding in the way we've chosen to use them, not intrinsic to the number format itself. \$\endgroup\$ – DMGregory♦ Jan 30 '20 at 2:30
  • \$\begingroup\$ @Raouf What is your value range for that though to get terraces? If you are measuring height relative to the planets centre, the resulting very high magnitude numbers massively limits small details. If you say 0 is "sea level", then you have lots of precision. \$\endgroup\$ – Fire Lancer Jan 30 '20 at 11:08
  • \$\begingroup\$ @FireLancer 0 is sea level, but you have a pretty good point. I didn't think about that this way before. Thanks! \$\endgroup\$ – Raouf Jan 30 '20 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.