Voxel Physics
This post looks at some of the common approaches to integrating physics with a voxels I've seen and used, as well as the approach I settled on for Terasology.
Before that let me clarify what I mean by voxel physics: supporting collision and hit detection of a voxel world, including individual voxels. This does not touch on voxel dynamics such as having floating voxels fall or detecting unsupported structures.
Integrate an Existing Physics Engine
This is an obvious path to take, particularly if already using a game engine with built in physics integration like Unity. Full physics behaviour with a variety of shapes is a complex area, so using an existing and hopefully well supported implementation is enticing.
The vast number of voxels as usual puts some constraints on how to approach this. Adding a collider per voxel will consume vast amounts of memory and perform poorly. A better approach is required.
One method that works reasonably well is to generate one or more collision mesh for a voxel chunk. Multiple mesh will be required if there are multiple collision behaviours - perhaps some voxels are solid, while others can be passed through but still can be targeted. Often this can reuse much of the mesh generation code used to render the world - but generally cannot be the same mesh due to differences between what is displayed and what can be collided with.
There are a few downsides to this technique:
Generating and updating the collision mesh takes time. This can be done on a background thread, but there will be a delay.
In some engines the mesh will be set up for rendering even though that is not required for your usage. This means it will use video memory and take longer to build.
Mesh colliders are paper thin, which means you have to be careful about objects passing through them. In particular when the collision changes due to a voxel being added, any object inside that space will fall into the collider.
The mesh use some amount of memory.
Extra work needs to be done after colliding with the world to determine which voxel was hit.
Another technique is to add colliders for each voxel, but just in the immediate area around players or other actors of interest. This has some immediate advantages:
Per-voxel collision with whatever collision shape best fits each voxel.
Can update immediately with voxel changes.
Small memory footprint, if the number of actors requiring collision is small.
The downside is the limited area in which collision works - you cannot do long-ranged ray traces, nor have objects bouncing around everywhere. Velocity can also be an issue, as a fast moving actor could exceed the collision area in a single tick. Still, this can work well for character movement and can be combined with other techniques.
Roll Your Own
Having seen the options for integration with a physics engine you may be thinking you could do better. After all, your voxel world is composed of a axis-aligned grid of primarily cubic objects - you can easily work out what grid cells are involved in any ray trace or potential collision. And this is correct to an extent.
Ray tracing is pretty straightforward. The ray trace need only step through the voxel cells - you can work out which cell is next from the side of the cell it exits from. Some care is needed for traces along the edge or passing through the corners of cells - these may need to hit all the cells they touch for correct behavior. Supporting non-zero extent traces (where the ray has a diameter) may also be useful.
After determining a cell is involved the ray can be tested against the shape of the contents. Axis-aligned boxes and spheres are simple, but more complex shapes are possible too.
The advantages of rolling your own are:
Can hook directly into world data, so little memory cost or delay in collision availability.
Performs well by taking advantage of the voxel structure.
Per-voxel collision info is easily available.
The problem with rolling your own physics is when to stop. Beyond ray tracing is convex sweeps, collision between moving objects, rigid body simulation, constraints... If you are primarily interesting in creating an engine then this may be ok, but if you have some other goal like creating a game then producing and maintaining a physics engine is a poor use of your time.
Extend a Physics Engine
This is the solution I went with in Terasology - take an existing physics engine and build in support for voxel structures. These structures can link directly to voxel data, providing all the benefits of rolling your own engine, but can take advantage of the collision algorithms and features of the existing engine.
The restriction is that you need access to an open source physics library or one with an api that supports the necessary extensions.
For Terasology I extended JBullet (a Java port of Bullet) and named it tera-bullet. The extension is a new Shape called a VoxelWorld. This shape provides the ability to request information on the collision shape of each voxel. The collision algorithms for VoxelWorld work out all the voxels involved in a collision and delegate the collision processing to their shapes.














