32-bit height map

[TokisanGames]

@ozzr suggested the option of using a 32-bit heightmap. I used this in mine as did Zylann. It allows us to drop the 0-1 scale * a fixed height, and instead just use full precision with "natural" heights. He suggested 16-bit for low end systems.

In my system I had a table where I hard coded load, edit, and game-play formats so I could specify the format for each and it would convert between them as needed.

[TokisanGames]

The current method has problems with floating point precision. Sculpt w/ flatten at 500 and you'll see it

Up close it gets really bad

Because of the 0-1 * max_height(1000) method, I need to import my terrain (range -300, 250) where 0 is offset to 500. That way we can sculpt down into the ground lower, or higher up to peaks. As a user, I have to use care to ensure my lowest possible point we'll ever do is >=0. If I get it wrong and decide I want to make one section lower, and it's already near zero, I'll have to sculpt the whole terrain higher. Or I'll have to export and reimport with an offset (which I'll build into the tool).

I thought this 0-1*height system would use full precision, but since that's not the case, there doesn't seem to be any benefit to this method and a big caveat of caring where the maximum limits are. We should just move it to natural heights as noted above then the user does not have to care, they can just sculpt down into the ground or higher, through the full 16/32-bit range.

I saved in either 16 or 32-bit, and edited in 32-bit, which I found necessary even if saving in 16-bit.

[TokisanGames]

Also as a user, it's annoying to only be able to sculpt upward. I can't start with a blank canvas and sculpt downward into negative values. That alone is worth changing for me, but the artifacts noted above are a problem as well.

[ozzr]

@TokisanGames I think that now there is a third option for using RGB encoded heights using the same approach that is following zylan for his heightmap plugin. This would allow to use Viewports for painting while also being fully supported on every platform

[TokisanGames]

Now that it's been over a month, what do you think of this method? Is it better than 32-bit? Does it allow for fine grained changes, as will be used during sculpting operations?

[TokisanGames]

Zylann decided to move away from encoding heights in RGB as integers.

His reasoning: Floats are easier, more precise and faster to work with, for the same memory usage on GPU.

So I think we can take this off the table. Current method has artifacts and is inconvenient to use. I see our best options as:

• Full range 32-bit editing and saving
• Full range 32-bit editing, 16-bit saving

[TokisanGames]

32-bit editing and saving has been enabled, with an option to save in 16-bit in PR #104.

Artifacts are gone, and we can now directly sculpt down into the terrain into negative values, rather than having to add height first, then down.

At a height of 500 or 5000 it's smooth: