I am working on a small voxel game which is similar in some aspects to minecraft. My plan is to implement some physics (when a block is floating in the air, it will be detected with a BFS and then have a physics mesh spawned in its place...).
Once it comes to rest it will then be snapped back to the grid (or crushed if it comes under enough pressure).
Or at least that is the plan.
Like minecraft, terrain is generated as the world is explored and that means the world size is theoretically infinite. I have a 2D integer coordinate system for each (chunk) and then floating point vectors which are used to describe the position of objects relative to the chunk they are in.
This seems to on the surface present a problem since when creating a world with bullet physics one must specify the size of the entire world (as an integer (I think) which may be too small to even pass the theoretical world limit).
I have thought about ways to get around this, prehaps have separate worlds (for each chunk/group of chunks) and then pass bodies which leave one world into the adjacent world with the same rotation, velocity etc, though I am not yet sure what effect this may have on performance.
Is this even possible with bullet or is there a better approach?
Thanks
Physics In an Infinate Chunk Based World
-
immortius
- Posts: 6
- Joined: Sat Aug 22, 2015 4:12 am
Re: Physics In an Infinate Chunk Based World
Doesn't directly address your problem, but you may find this useful: btVoxelShape for grid-based world support.
On infinite worlds... I guess I've always felt it isn't an issue worth trying to solve. Does the player derive gameplay benefit from existing in an infinite world over merely a very large world? Is this benefit sufficient to make it worth addressing the complexity involved in supporting it? Traditionally the issue with procedural world games hasn't been the size of the world, but in the detail of the world - in avoiding everything feeling samey. The pay off for addressing that would be far larger than giving players an infinite amount of the barely distinguishable terrain.
I guess the way I would approach it for bullet though is having multiple worlds, one for each chunk or a set of chunks, each with a local coordinate system. I would suggest these would need to overlap rather than merely touch, otherwise you would have instabilities in rigid bodies stradling two worlds and other problems (consider what happens if a rigid body is passing into another world, and there is a wall where it is passing into). Probably will have some instabilities anyway due to floating point differences.
On infinite worlds... I guess I've always felt it isn't an issue worth trying to solve. Does the player derive gameplay benefit from existing in an infinite world over merely a very large world? Is this benefit sufficient to make it worth addressing the complexity involved in supporting it? Traditionally the issue with procedural world games hasn't been the size of the world, but in the detail of the world - in avoiding everything feeling samey. The pay off for addressing that would be far larger than giving players an infinite amount of the barely distinguishable terrain.
I guess the way I would approach it for bullet though is having multiple worlds, one for each chunk or a set of chunks, each with a local coordinate system. I would suggest these would need to overlap rather than merely touch, otherwise you would have instabilities in rigid bodies stradling two worlds and other problems (consider what happens if a rigid body is passing into another world, and there is a wall where it is passing into). Probably will have some instabilities anyway due to floating point differences.