GPU Terrain

[Firefly]

How can terrain physics be handled when a lot of modern terrain rendering is done via the GPU?

Normally for brute force approach and small heightmaps you could create vertices on the CPU and load them into Newton as a collision mesh but with GPU approaches there is no 1:1 mapping of vertex data on the CPU to whats displayed on screen. One idea was to generate a low-medium resolution version on the CPU to form the collision mesh but I'm not sure how practical this is as it may cause visual artifacts with physics objects sinking into terrain or perhaps even floating.

The other concern I have is that with large data sets there would be a need to perhaps stream collision meshes in/out of memory. Does Newton currently support this sort of thing?

Cheers

[Julio Jerez]

The heighfield data that is passed to newton is copied, so the terrain is independe of the visual data.

[Firefly]

Yes I understand that, but I was referring to modern terrain rendering techniques that don't necessarily store a high resolution version of the heightmap CPU-side but rather use a low resolution and tessellate or use other LOD schemes. I think I found my answer anyway, and was what I thought - basically give Newton a medium resolution version of the heightmap (lower memory consumption) and when rendering it would use different LOD's.

I have a couple other questions though:

1. For large terrain/worlds, does Newton have any notion of streaming "chunks" in and out of memory?
2. Can the collision mesh of a heightmap be modified dynamically? I'd like to be able to have "destructible" terrain where craters could be formed dynamically. This is fine in terms of updating the heightmap data, but would I have to re-create the entire collision mesh or is there a way to update regions?

[Julio Jerez]

You can use a uses defined static collision.

Code: Select all

NewtonCreateUserMeshCollision (world, &minBox[0], &maxBox[0], this, PlaneCollisionCollideCallback, PlaneMeshCollisionRayHitCallback, PlaneCollisionDestroyCallback, PlaneCollisionGetCollisionInfo, PlaneCollisionGetFacesInAABB, UserCollisionSerializationCallback, 0);

And you have to implement a couple for functions.
Basically the in the call back you provide a vertex list index list of the faces that intersect a box aligned the space of you terrain.
There is a demo in file: ...\applications\demosSandbox\sdkDemos\toolBox\UserPlaneCollision.cpp
In fact tha is the same function use internally for collision tree and for height field


as for modifyind the mesh, yes you can do that, however the engine does resolve penetration on bodies that where on the surface of a patch automatically.
if a body was resting on a terrain and you move the vertices and they now penetrate, the engine will no have a way to know that you modified the terrain
you will have to explicitly notifiy by waking the body.

[Firefly]

So basically what you're saying is to use a "user-defined collision mesh" for chunks that are being stream in and out? That sounds reasonable to me. Looking at the SDK I can see Newton has serialization abilities too which is great as I can use that to pre-calculate initial collision meshes for the chunks.