Would qu3e be a good base for "distributed physics"?
Closed this issue · 3 comments
A question, not a bug/feature request...
I'd like to make a sandbox/voxel-based/space-sim game. I'll be using UE4, and I'm buying as much pre-made assets as I can, as I'm no "game dev". UE4 has PhysiX built-in, but the one thing I wanted to achieve is that the game server is "fully distributed" (I'm in charge of "clustering" at work, so that's my "specialty" and my main interest), but I understand that getting PhysiX (or most physics engines) to work in "distributed mode" would be a giant undertaking. I have found someone doing that for PhysiX, but they are not sharing their code (yet). And the one or two commercial options are out of my financial reach.
My general strategy is breaking the universe into a large-scale 3D "grid", and each "grid cells" withc active entities (each maybe 1KM^3 in size) is allocated to a cluster node, such that nearby cells are on the same node. The entities in a node would then be broken up in "independent groups" (islands?), and each group would be assigned a thread (fixed-size thread pool), with each thread having one (or more?) separate "physics engine" instance.
The real problems come when too many entities are in a single thread/node, because they are all close enough to interact. My understanding is that at that point, you have break up the group and replicate the physics data over the cluster, such that each entity is managed by exaclty one physics engine instance, and acts like a "kinematic body" in the other instances where it can interacts.
Do you think qu3e is "hackable" enough, to be turned into a "distributed physics engine"? How would you go about it?
Since qu3e doesn't have much code or make use of complicated C++ features, it is quite hackable. I have never implemented distributed physics stuff before, but from your description it could be possible to use qu3e. Just be weary that if you ever do need more than just OBB/AABB, using qu3e is not a good option since it literally only supports OBB/AABB shapes.
No matter which engine you use, certainly making a robust distributed physics solution would be a massive engineering effort, so much so that picking a particular physics solution is probably not all that important in perspective.
Thank you for your reply. I'll interpret it as "The best you can hope for (given limited time), is to distribute the islands over the cluster, and hope each island "fits" in a single node".
One way I thought of implementing this, is to have two "global arrays", with the "physics data" (shape, position, mass, ...) of each object either "owned" by the current cluster node, or close enough to any of those objects to interact. Each object would compute the collisions for themselves based on the (read-only) "first array" in parallel, and update only their own data in the second array. At the end of the cycle, the arrays are swapped and, assuming the network is fast enough, the "changed data" is broadcast to the rest of the cluster cluster. If a collision involve two objects (but each object can have multiple collisions), it seems to me I would double the collision processing, but make "trivially parallelizable". Since doubling the number of nodes in a cluster is cheaper than doubling the processing power of each node, in theory I could probably afford it.
What do you think would happen if I tried something like this? There is probably something I failed to consider...
I can't really help you much more than I have, since I haven't worked on this kind of stuff before. One thing to consider though is floating point determinism across your cluster, and whether or not you need it for the physics sim.