Implement physics in blocky voxel game

Good evening jMonkeys!

I’ve been thinking a lot about how to implement physics in my blocky voxel game. Since there is some complex models in addition to the meshes for the chunks created by the greedy mesher, i guess its way more convenient to go with bullet instead of implementing collisions and other physics myself which could be a valid option probably for simple ‘block-collision’ checks.

Since I’m aiming for multiplayer i came up with the following idea:
There is a class that, given some players, can calculate all chunks that are in ‘physics range’ (its less than viewdistance which is already less than load distance) of any of the given players based on their position.
As soon as this check realizes that one or more chunks are in physics load range for several players, all these players and all chunks in physics load range for any of these players are put into the same physics space.
Other way round too ofc, as soon as it realizes that players who shared one physicsspace dont share any chunks in their physics load range anymore, are split up into as many physics spaces as needed dependant on how many players there were and how many of them left that ‘batched’ region.

Now before implementing all that physicsspaces handling i want to make sure its actually worth it and there is no better way of doing it. If i consider the scenegraph and think about parent-child-relations im wondering if there is a way to basically ‘add several physics objects to one parent-node-thing so when collisions are to be calculated and one object realizes it doesnt collide with the bounding box of the parent-node-thing can skip checking collisions on the small objects’ or is it organized like an octree and thus would basically do the same optimization?
These approaches would basically remove the need to split up the physicsspace, at least in this case.

And lastly, sounds like the one most nooby question, and probably also is, but i do still struggle with it especially if i consider to use several physics spaces:
Which operations do i need to do on the main thread (yeah ofc all that change the scenegraph) and which operations can be done on the physics thread? (Assuming I would go for parallel mode even if i dont use several physicsspaces, those threads differ). Reason i need to ask it is: For now i load my chunks on the loader thread(s), mesh them on the mesher thread(s), and then first queue them to be grabbed by a control that adds them to the scene with some maximum number per frame and secondly also handle them to the collision shape creator thread(s) that would create the shape and in an physicsspace.enqueue() call add it to the physicsspace on the physics thread . That can lead to situations where the mesh could be accessed concurrently by creating the collisionshape on a collision shape creator thread and adding it to the scenegraph on the main thread. It should be fine since its both only reads?
Just wondering since i got some ‘a fatal error has been detected by the java runtime environment’ complaining EXCEPTION_ACCESS_VIOLATION, for call CollisionShapeFactory.createMeshShape but i got a feeling it is because the collision shape creator tried to calculate the collision shape for a mesh that is currently getting removed and deleted since it only appears when i move back and forth really fast in flymode and chunks might get remeshed before their collision shape was calculated.

id appreciate any idea, experience, opinion or pointing into some direction related to physics in blocky voxel games especially multiplayer related stuff a whole lot so thanks in advance :slight_smile:

Greetings from the shire,
Samwise

1 Like

Imma stop you right there. Using a general physics engine such as bullet on voxel terrain may be more trouble than it’s worth.

I can’t say I have any experience about it myself but I’ve seen it said a handful of times on the forum.

@pspeed ought to know just about everything there is to know about that however.

It’s a complicated problem. I guess folks who have used the cubes plugin thing were able to get bullet to work. Even with what I know about bullet now, it feels like it would be tricky.

…but I come at it from the perspective of having made my own physics engine built from the ground-up to handle this sort of paging. I do not recommend that route if you can get bullet to work for you.

I’m assuming you mean an ‘infinite world’ type of situation… or at least large enough not to fit in one single physics space.

You will definitely need some kind of paging system for your terrain and the server will need to be able to access that to load ‘chunks’ of the world. How you manage that with bullet is up to you.

My own system (someday to be open source), keeps track of zones and what objects exist in which zones so it can activate/deactivate them as needed. In bullet, I guess you can have separate spaces but then you will need to figure out what to do when they overlap… could be that you just tear the separate parts down and merge the spaces. I never thought about it much because I’d already invested so much time into my own approach.

Bullet is a better physics engine than mine is. (Still, it was nice to see the same physics glitches in both engines… just the nature of it sometimes.) In one of the threads on here you can find more information about what I was doing. I don’t remember if I posted videos or just images.