• Advertisement
Sign in to follow this  

Physics engines that support terrain defined using voxels?

This topic is 2984 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been scouring the web looking at different physics and rendering engines. At the moment my program does rendering via opengl directly, and there is no realistic physics involved. The main feature I'm looking for is a way to convert my current voxel-based deformable terrain into a format that a physics library can interpret and apply rest forces, collisions, etc. The voxel terrain is a grid, covering all of space, holding signed-distances to the surface, that is, increasing negative inside and increasing positive outside the terrain. This means calculating distance to, and surface normals at, any point on the terrain is trivial. I have used this fact in a simplified form to add particle-critters running around the surface. However, I now need to add some realistic rigid body physics to those critters. I polygonise the voxels to create a triangle mesh for rendering, using Marching Cubes. This could also be used for collision detection, but it seems like it would be more effort. I would rather skip the middleman and use the underlying grid values. Its a long stretch to imagine any physics engine will have support for this out of the box (?), but maybe there are add-ons or something? If not, can anyone advise the best way to go about integrating such a form of terrain into one of the major physics engines (I particularly like Bullet from what I've read, but I'm open to suggestions)?

Share this post


Link to post
Share on other sites
Advertisement
I have a similar setup to you, in that I have a world defined by voxels and I use the Marching Cubes algorithm to generate the triangle surface (see link in my signature). I am currently using Bullet for the physics simulation, but am having it operate on the trianlge mesh rather than the the voxel data.

I do agree it would be interesting to use the voxel data instead but haven't don't much research into this yet. However, I believe that Bullet offers some kind of 'Heightfield Shape' for collision detection. You should investigate this and find out whether it could be generalised/extended to handle voxel data.

I'll be interested in your findings at any rate.

Share this post


Link to post
Share on other sites
Hello, my engine uses voxel data as the primary representation for both physics and rendering. You can check it here:

atomontage

Today I have released first game-like scene video including vehicle physics and similar.

I don't see a point in getting back to non-atomic representation (polygon meshes, collision primitives, ...) as it seems to slowly become widely accepted that voxels are the right way to go (I know that since ages ;) .


In a not so distant future I will present some more advanced physics like thermodynamics, larger-scale destructions (now only wheel-tracks and similar small-scale destructions work well) and much much more.


Hope you enjoy it!


Brano/Atomontage

Share this post


Link to post
Share on other sites
Quote:
Original post by dangerdaveCS
I've been scouring the web looking at different physics and rendering engines. At the moment my program does rendering via opengl directly, and there is no realistic physics involved.

The main feature I'm looking for is a way to convert my current voxel-based deformable terrain into a format that a physics library can interpret and apply rest forces, collisions, etc.

The voxel terrain is a grid, covering all of space, holding signed-distances to the surface, that is, increasing negative inside and increasing positive outside the terrain. This means calculating distance to, and surface normals at, any point on the terrain is trivial. I have used this fact in a simplified form to add particle-critters running around the surface. However, I now need to add some realistic rigid body physics to those critters.

I polygonise the voxels to create a triangle mesh for rendering, using Marching Cubes. This could also be used for collision detection, but it seems like it would be more effort. I would rather skip the middleman and use the underlying grid values.

Its a long stretch to imagine any physics engine will have support for this out of the box (?), but maybe there are add-ons or something?

If not, can anyone advise the best way to go about integrating such a form of terrain into one of the major physics engines (I particularly like Bullet from what I've read, but I'm open to suggestions)?


Being able to calculate distances and normals is a good first step, but it doesn't get you all the way there since it doesn't really handle the collision detection part. Most collision pathways in Bullet (and Havok, and pretty much every physics engine) are for convex shapes, which a voxel terrain probably isn't. You can't really use sampled heightfields, etc. in those engines because they assume no overhangs.

I see two good approaches to handle this problem:

1. Convex decomposition into convex hulls. This is a fairly non trivial algorithm to build, but basically you should be able to group your voxels into convex pieces. Then feed those pieces (as a point cloud) in to a convex hull builder. A terrain made up of convex hulls will be extremely fast compared to an actual mesh, and go through established and well tested parts of whatever physics engine you're using. You can run your own code at tool time, making it easy to test.

2. Build a collision "agent" between your voxel terrain and whatever shape types you want in your game. If you only have a few simple types in your game (spheres, boxes, capsules, etc.) this could work. If you want to collide against actual meshes or convex hulls, etc., this could become an inordinate amount of work. Plus each agent you write is a potential point of failure that you won't get support for, and writing agents often involves intimate knowledge of the engine you're using.

Share this post


Link to post
Share on other sites
@PolyVox: thanks a lot for the pointers. I remember you've answered in a few of my previous threads as well, so thanks a lot for those also.

The btHeightfieldTerrainShape, which is I think what you meant, looks like it only supports a 2D input. Maybe there is some hope in extending one of the CollisonShape superclasses, but I would have to spend an age analyzing the code.

@Brano: looks like your engine is going to be awesome! Any hints on how you add physics to support your rigid bodies (like that truck) moving across the terrain?

EDIT: @Numsgil: Thanks for those suggestions, sound intruiging. Is it still worth decomposing into convex hulls though, considering I already have the triangle mesh I use to render the surface, and could just use that instead? What do you mean by 'collision agent' - sounds interesting?


My first instinct was to use the underlying voxel data to calculate surface normals and then use these to apply forces/impulses to the rigid bodies. I'm not as well up on rigid body simulation as I should be, but I believe such an approach could make the bodies just continuously bounce, unable to find a stable state?

Do you think it would be possible/feasible to use a force based approach for bodies that move across a surface, how could I go about it?

Share this post


Link to post
Share on other sites
Quote:
Original post by dangerdaveCS
EDIT: @Numsgil: Thanks for those suggestions, sound intruiging. Is it still worth decomposing into convex hulls though, considering I already have the triangle mesh I use to render the surface, and could just use that instead?


Yes. Though it would involve more work. Convex hulls are considerably faster than meshes, because meshes must treat each triangle individually while convex hulls can be treated as a single piece (using GJK, for instance). But you could use your triangle data if you like. If you do, be sure to wrap it in some sort of bounding volume tree.

There might be a way to convert the mesh itself in to a collection of convex hulls. I'm not sure what sort of tools are freely available. It's a gnarly problem, though you could probably hack together something with a few days of work. The hard part is just segmenting the voxels (say, point cloud) into convex pieces. Building the hull around a point cloud is a well studied problem with lots of freely available code to handle it, and Havok (and probably Bullet) has code to handle it anyway so you wouldn't need to write that part.

Quote:

What do you mean by 'collision agent' - sounds interesting?


Not sure if it's a standardized term, but Havok (and I'm guessing Bullet) has the idea of an "agent" which handles collision between two different types of objects. So a sphere-sphere collision might go to a different code path (agent) than a sphere-box collision. So you could write your own agents and plug them in for your own custom voxel shape. Box and sphere to voxel is probably not too hard, but mesh to voxel collision detection would get ugly really quickly.

Quote:

My first instinct was to use the underlying voxel data to calculate surface normals and then use these to apply forces/impulses to the rigid bodies. I'm not as well up on rigid body simulation as I should be, but I believe such an approach could make the bodies just continuously bounce, unable to find a stable state?

Do you think it would be possible/feasible to use a force based approach for bodies that move across a surface, how could I go about it?


As I see it the hard part isn't applying forces and the like. That's what the physics engines are already good at (collision response). The hard part is determining where a geometric shape is in collision with a voxel shape (collision detection). The voxel shape isn't necessarily convex, so you can't use GJK. Concave collision detection usually consists of breaking the concave piece in to convex parts anyway.

Unless there's something I'm not seeing and the collision detection code is quite straightforward?

Share this post


Link to post
Share on other sites
Quote:

Brano: looks like your engine is going to be awesome! Any hints on how you add physics to support your rigid bodies (like that truck) moving across the terrain?


thanks! polygon-based objects interact using hierarchies of collision primitives, but soon I want to re-enable a voxel-based collision representation for this type of objects (it already worked well in an older implementation of my engine)

Brano/Atomontage

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement