Performance Question for Terrain

[Empire-Phoenix]

Hi, I currently have a dataset of 1024x1024 points as Shorts in 1 meter distance as a grid. (It is planned to cramp that up to 16kX16k at max)

Currently I use the btHeightfieldTerrainShape however I get really hard slowdowns when doing ray tests or having collisions with larger objects (eg a 100 meter sphere falling down).
The question is, would I be faster with a btBvhTriangleMeshShape (due to better optimizations) or would it perform even worse?

Any help would be very appreciated.

[MaxDZ8]

Replying so I get a notification.
I never had this need, but it's a very interesting problem.

[xexuxjy]

I suspect you'll get very similar behaviour with the BvhMesh (in fact possibly worse), the standard behaviour of both the Bvh and the Terrain mesh is to identify the individual overlapping triangles in the object then test each of those as a (in this case) sphere v triangle test. in your example with a 100m sphere you're going to be getting an overlap of 100x100 (*2) triangles each of which will be tested with no option of escaping the test.... Perhaps Erwin or one of the other guru's here could provide an alternative approach to this?
Ray casts on a bvh may be better then on a terrain shape, particularly for diagonals (terrain creates a simple bounding box based on the ray which will generate n^2 tests for the pure diagonal rather than n tests for a pure horizontal or vertical)

[Empire-Phoenix]

Ok actually after a few tests, i must say that the optimized shape performes much better, as it seems to only need to do the more expensive operation when an object is very close to hitting it, while the terrain does stuff way before that. -> This reduces the average load quite considerably.

[137Cs]

What happens if you split the terrain into, say, 256x256 chunks?

[Empire-Phoenix]

Well thats still a totest, before that I'm trying to get the still missing features to work, then I will try to optimize.

Currently I have a 4kx4k grid that works (i figured, that using one data point every 4 meters is fine enough for a largescale terrain)

When disabling the QuantizedAabbCompression of the btBvhTriangleMeshShape the load time is acceptable (around 30 seconds).

Now i'm in the process of trying to update the data-grid, (setting the height of single points to a different value)

The mesh is shared via a btTriangleIndexVertexArray (Position 3*4byte signed float vectors and IndexBuffer 1*4byte signed int) wich then is used to construct the btBvhTriangleMeshShape.

This works all fine untill here, if i do rays , collision ect everything works as expected.

For this my current process is to change the Position/Vertexbuffer accordingly (this step should be right, since when I render the mesh it looks fine). Then I call partialRefitTree for a cube containing the changed vertices. (well currently i just use a aabb that covers the whole terrain, since it did not work).

The actual problem now is;
I have a Rigidbody (boxShape) resting on the terrain. I call once per frame activate to make sure it is not sleeping. When I now lower the terrain below it, sometimes the box rests on the lowerd ground, but often it just falls trough. (Even respawning it above the terrain and letting it fall again it just passes right trough)

Does anyone know where I have a logical error, or if i misunderstood the purpose of partialRefitTree?

[Empire-Phoenix]

Ok update.

I found that the refitTree(partialefit Tree) do not work reliable, wich is why i switched to regenerating the whole Meshshape if changes happen.

The terrain is now tiled into blocks (eg 256x256), each needs only a few ms to be generated. On start all blocks are generated, but not attached, since then the broadphase seems to go down.
Now i track my phsic objects and if a collision might occur i add the tile to the physicspace, and after some minutes without collision i remove it again. A secondary queue is implemented to track requested updates, wich then generate the new shape in a background threadpool, and submit the changes to the main physics thread which then replaces the shapes.

Pro for this solution, terrain size is irelevant for performance, only the initial load time increaes linearly with the surface of the heightmap. The performance is only determined by the maximum amount of active rigidbody with mass > 0, as they limit the maximum amount of added tiles.

Contra is of course, that changes needs around 200ms before they reflect into the scene, since first the new shape needs to be ready (Also all that threading makes it a bit more complex).