Compound HeightMap for HeightFieldShape

[AlexAPPi]

Hello! I am focused on web games development using WebGL2/WebGPU. I have created a HeightFieldShape type for Ammo.js, taking into account the specific features of web platforms, to efficiently store data and facilitate loading it into GPU memory. Could you please review our solution and let us know if you would be able to accept our PR?

The data is stored in patches, allowing them to be packed into a texture array and updating individual layers as needed. This does not require allocating new memory — the same memory is used throughout the entire process.

The compression algorithm allows us to use formats such as Float32, as well as combinations like (Uint16 + Uint16) and (Uint8 + Uint8 + Uint8 + Uint8) to save space. We overlay patches on top of each other, which enables their combination and convenient reuse on the GPU side.

https://github.com/AlexAPPi/playcanvas-terrain-system
https://github.com/AlexAPPi/ammo.js/blob/AlexHeightfieldTerrain/bullet/src/BulletCollision/CollisionShapes/btAlexHeightfieldTerrainShape.cpp

[jrouwe]

I think you're posting this in the wrong place, ammo.js is based on Bullet Physics not Jolt Physics.

[AlexAPPi]

I think you're posting this in the wrong place, ammo.js is based on Bullet Physics not Jolt Physics.

Thank you for your response. Yes, the link to the PR is related to Ammo.js, but we plan to implement something similar for your Jolt engine. I would like to suggest creating something similar for your physics engine.

[jrouwe]

The HeightFieldShape is the most complex shape in Jolt (clocking in at 2700 lines). It has a very tricky internal acceleration strucure + variable compression scheme to make it small and fast. Height fields can already be (partially) updated on the fly through HeightFieldShape::SetHeights without triggering allocations (if you don't count allocations in the temp allocator). I'm not planning on supporting additional versions of this shape as it would be too much of a maintenance burden for me.

[AlexAPPi]

The HeightFieldShape is the most complex shape in Jolt (clocking in at 2700 lines). It has a very tricky internal acceleration strucure + variable compression scheme to make it small and fast. Height fields can already be (partially) updated on the fly through HeightFieldShape::SetHeights without triggering allocations (if you don't count allocations in the temp allocator). I'm not planning on supporting additional versions of this shape as it would be too much of a maintenance burden for me.

https://github.com/jrouwe/JoltPhysics/blob/master/Jolt/Physics/Collision/Shape/HeightFieldShape.cpp#L89

Here, there is a concern regarding data storage: float32 is memory-intensive, so it is necessary to add support for more efficient types such as uint16 and uint8.

For example:

factor = inSamples[x + z * inSampleCount]

float32: height = (factor * (maxHeight - minHeight) + minHeight) or factor
uint16: height = (factor / float(0xffff)) * (maxHeight - minHeight) + minHeight
uint8: height = (factor / float(0xff)) * (maxHeight - minHeight) + minHeight

[jrouwe]

The HeightFieldShapeSettings is only used during HeightFieldShape construction. Afterwards it can be destroyed. You can do this offline and use SaveBinaryState / sRestoreFromBinaryState to serialize and restore the optimized heightfield. That way you'd totally avoid extra allocations and extra CPU overhead. Note that these last 2 functions are currently not exported to the JS runtime but they could be.