Any way to use unsigned shorts for heightfields?

[pHySiQuE]

The old unsigned short data was better for heightfield collisions:

• It took half as much space.
• It could be sent directly to the GPU as texture data. Many float texture formats get clamped, so sending the terrain data to the GPU involves iterating through and converting thousands of data points.

Is there any way to regain that functionality, instead of using full floats?

[Julio Jerez]

actually for collision float are better, the amount of space is twice as large.

what do you mean GPU? the data of the high field is in system memory?

yes we can make the terrain use both unsigned or floats, in my opinion the saving are so minimal compared to the code complexity.

what are you doing that is using so much memory?

I am actually working on the terrain now I am adding more variance for grid construction.

mode 2 is like this
|/| /|
|/| /|

mode 1 is like this
|\|\|
|\|\|

now more 2 is like this alternate even rows
|\| \|
|/|/|

now more 3 is like this alternate od rows
|/|/|
|\|\|

now more 4 is like this alternate even columns
|\|/|
|\|/|

now more 5 is like this alternate odd columns
|/|\|
|/|\|

now more 6 is like this alternate even columns and eve columns
|/|\|
|\|/|

now more 7 is like this alternate odds columns and eve columns
|\|/|
|/|\|

that cover all of the possibilities to lay pout a terrain

[pHySiQuE]

Our renderer does a texture lookup in the vertex shader to control terrain height. Then we just render an identical patch over and over, and use the texture to control the vertex height. This allows us to render terrain very fast, using just 32 mb to store a 4096x4096 terrain.

We also perform terrain editing on a GPU using a shader, which makes our terrain editor silky smooth. With unsigned shorts, we can transfer data to and from the GPU with no processing of each point. Otherwise, we have to iterate through the entire heightfield and divide the floating each point value by an arbitrary maximum height because it will be clamped between 0 and 1 when sent to the GPU.

We presently support terrains up to 4096x4096 points, which works out to 32 mb using shorts. However, I want to use 64-bit floats in the future and support terrains up to 16384 x 16384, for flight sims. That takes a gig of memory with floats, and only 512 mb with shorts. Our engine can be compiled in 64-bit mode, but our editor can only be compiled in 32-bit mode at this time, so minimizing memory usage is important. I do have a user with a commercial flight sim in development that would like to take advantage of these giant terrains.

So halving that data by using unsigned shorts instead of floats will make a big difference, in terms of memory consumption and data transfer speed to and from the GPU.

[Julio Jerez]

Oh I see, I will add the option of using 16 bit unsigned or 32 bit floats, that will result that issue.
I will check that in sometime tonight.

[pHySiQuE]

Thank you! Together with the low-memory scene collision class, this will allow Newton to make extremely large worlds.

[Julio Jerez]

Ok done.
I did not tested but I believe it should work fine.

[pHySiQuE]

Cool, will check it out.

[pHySiQuE]

So far, so good.

Thanks again.

[pHySiQuE]

I made a correction so collisions will work:

File: dgCollisionHeightField.cpp
Line: 878

Change this:

Code: Select all

dgFloat32 high = dgFloat32 (elevation[base + x]);

To this:

Code: Select all

dgFloat32 high = dgFloat32 (elevation[base + x]) * m_verticalScale;

[Julio Jerez]

Oh that was a bug, but you fix is also a bug. your fix will make so that using unsigned will have a different scale than when using float.
I added the fix and checked in it.

sync again and it should be fine now