Moving vehicles and child objects

[Clonkex]

Apologies for the long post!

I'm experimenting with creating a space game. Any objects inside a space ship should move perfectly with the ship, as if it had magical inertial dampers. My original plan (using Godot's Bullet implementation, before multiplayer proved I had insufficient control over the physics engine) was to have a separate physics world for outside the ship and inside. Any objects inside the ship would have their rigidbodies centred around the origin, and their visuals would be offset by the ship's location within the outer physics world.

The primary issue with this is simply the transition. How do you have a rigidbody go from inside the ship (in one physics simulation) to outside the ship (in another simulation)? It's easy if you just have a teleporter to get in and out of the ship, but I don't want the easy route. I want to be able to open the cargo door of my ship and step out into space!

I've messed around with ideas like this in the past. For instance, at one point I made a portal engine in Unity, which meant duplicating rigidbodies and having the "shadow" copy attempt to get to the pose of the "main" object (basically how the real Portal did it). I don't like this solution because it's really hard to resolve two independent rigidbodies being connected by a magical spring force between physics simulations, and it's tedious to maintain two copies of a rigidbody.

I previously experimented with making a space game like this in Unity. Since Unity allows stepping the physics engine manually, I was able to get it working-ish. What I did was have everything in the one simulation, but set rigidbodies to dynamic and kinematic as necessary. So for each physics frame, I would start at the smallest interior space (inside the smallest ship) and set all the contained rigidbodies to dynamic. Everything else (including the containing ship itself) would be set to kinematic. I would step the physics, then move up to the next level. Everything at the smallest space would be kinematic and only the stuff at the next size up would be dynamic. Step the physics again and manually update the positions of the "contained" objects to the new position of the "containing" object. This works, but has a few downsides. First, it's super tedious and hard to get right (you have to track a tonne of offsets and be very careful to do things in the right order). Second, it's presumably kind of slow because stepping the physics engine would have overhead (untested though). Third, objects inside can't interact with objects outside other than by running into them (this isn't super bad but I would prefer to be able to shove boxes out of my ship without said boxes becoming immovable walls when they have exited the ship but the player hasn't yet).

Now that I'm using Bepu, is there a better way? My ideal solution would be to just run a single simulation with everything in it, but have all rigidbodies marked as "inside" a ship inherit any velocity changes to that ship (recursively, so that ships inside ships could work). The other goal is to have it so that objects inside the ship can't impart forces into the ship itself (because I fear running into stability issues if I make the ships themselves realistically heavy, and because player characters move using magical forces, which would result in being able to push the ship from inside).

Any thoughts or creative suggestions welcome :)

EDIT: I suppose what I'm after is a one-way fixed constraint 🤔 Movement from the ship also moves anything attached to it, but movement from the attached objects doesn't move the ship, even if they collide with it (which I suppose would be self-collision in the context of a constraint) 🤔

[RossNordby]

Unfortunately, any time a physical inconsistency is introduced, it pretty much guarantees complexity and pain.

One of the more consistent options would be to use a single simulation that implements the 'inertial dampener' explicitly. That is, directly apply forces to everything within the ship (and equal and opposite forces to the ship) to counterbalance unwanted internal accelerations caused by thrusters firing, turning, getting smacked, and so forth.

Embracing this fully would imply that stuff like characters and internal gravity work in a physically conservative way too. Magic character acceleration would indeed be able to shove the ship around. This adds difficulty, but if I were doing something like this, it's probably the way I'd do it (and is the way I did it, when I prototyped it about a decade ago :P).

Abandoning that physical consistency pretty much requires resorting to layered hacks. One of the simpler ones is probably the "inside of the ship is a separate simulation" option, with the requisite jumping through hoops to handle transitions between the internal simulation and the outer simulation. For example, objects exposed to space (or objects interacting with those objects) would transfer over to the space-level simulation and you could apply a one-way hack inertial dampening effect that fades as the objects become more exposed, and have those objects only collide with the ship's kinematic proxy to avoid direct feedback loops. There would still be potential loopholes that could be exploited, but the idea would be to limit their scope enough that they don't break the game. At least not always.

In other words, there are no great options without consistency, just varying levels of ouch. Probably best to stick to the simplest options since they're all gonna have problems.

I suppose what I'm after is a one-way fixed constraint 🤔 Movement from the ship also moves anything attached to it, but movement from the attached objects doesn't move the ship, even if they collide with it (which I suppose would be self-collision in the context of a constraint)

Something like this can be done by allowing collisions to only occur with a kinematic proxy of the ship. The kinematic proxy matches the pose/velocity of the "real" ship, but collisions or constraints associated with it cannot change its velocity because it's kinematic. Still have to be careful with this kind of approach- imagine a cargo box getting stuck between its source ship and an enemy ship ramming it; the enemy ship would hit the cargo box, the cargo box then hits its source ship that it treats as kinematic, the enemy ship then comes to a complete halt as it feels the infinite mass of the kinematic proxy, and the source ship feels nothing.

[Clonkex]

Thank you for the exceptionally intelligent and detailed answer! It's great to talk to someone who's very knowledgeable about the physics engine but also knows when to speak in practical gameplay terms.

I completely forgot that I'd already thought of implementing the inertial damping as a gameplay mechanic (a shower thought, which I apparently forgot again). That suits me very well since I already want ship systems to be a part of the gameplay. Not to mention I've learned that doing things the "most-correct" way almost always works out a whole lot better than trying to cheat. The difficulty is in recognising when you're trying to cheat, and taking a step back to look at the problem more completely.

I've been working on the building a layer on top of Godot to let me easily create multiplayer games the way I want to (specifically, the entity, multiplayer and physics systems, which are useful to any game) but I've been half-dreading figuring out how I'm going to handle physics inside ships. My backup plan was always a secondary simulation with a teleporter to enter the ship, but I really wanted to avoid that if I could. I'm now excited to get to the ship implementations because I have a clear idea of how I can do it (the in-game inertial damper). Can you read forces from a rigidbody that have been added since the last physics step? Otherwise I'll put a layer on top of the direct rigidbody "add force" methods that can track what forces have been added. It won't capture collisions, of course, but I'm not actually too worried about that. It provides more gameplay incentive to avoid hitting things if all your stuff gets thrown around the ship when you crash 😁 I'll just have to be a bit careful to avoid tunnelling if I allow people to crash at high speeds without blowing up. I suppose the other difficulty is when a force is applied to the ship off-axis (such as when turning), I think I need to scale the opposing force on the object inside by the distance from the centre of mass of the ship. Or something like that, I haven't thought about it yet.

The kinematic proxy is a clever idea. I'll see how well the game plays without it for now, but I think the general idea could be very useful in some situations.

Also in case you're wondering (and for future reference for other people), I'm doing floating origin to handle large distances. That's easy enough on the client, but on the server it's hard because it has to process the entire universe at once. On the server, I find clusters of nearby rigidbodies and group them into their own simulations. It does mean that if you lined up a heap of very large ships end to end, reaching across a very large distance, you'd technically be able to run into a situation where some rigidbodies might be simulating far from the origin, but the chance of that actually happening is very low so I'm ok with the possibility.

Thanks!

[RossNordby]

Can you read forces from a rigidbody that have been added since the last physics step? Otherwise I'll put a layer on top of the direct rigidbody "add force" methods that can track what forces have been added.

Probably will need a layer. You can compare the current velocity to the previous velocity, but that includes all changes baked together regardless of source.

[damian-666]

just chiming, in.. Wth physicis its all or nothing. go 100% or go home. Thats why true physics games dont exst or get cancelled. this has been gong on since 1994. ( Jurassic Park Tresspasser) like Ross says. "Unfortunately, any time a physical inconsistency is introduced, it pretty much guarantees complexity and pain." i have characters that ride surfboards and walk rope bridges. FREE. i put powerd ragdoll on a board n water and it works. he surfs. problems is... takes years to make a powered ragdoll. took me 5 years to develop my controller in my own brain, in myo own body w morphology trained ove 30,000 + years, to learn to do a cutbacko n a real ocean wave on a surfboard.. and 3 yeasr to walk on flat ground. robot engineeers arent cheap or available. If you want to succeed ths way you have to learn robotics, multphsyics, and not use any kinematic bodes. HOever.. a walking bided game has never been done withotu marionette forces.. Those wlll introduce artifacsts so i refuse to use them. bgut You can get awway why thos, you cna cheat a bit "Maradonnas " hand of God.

I would suggest using a thick air field in the ship. Ths wold be a basic drag velocity filed. When yhou put the air in the shiip it will move the characters about. Aslo you will have to put airlocks in to go for a space woak. But you get the side beneifts of ... breached hullls. Charactsr sucked out into space ect. for example.. i do a fake gravity... i rotate my ship an walk on the inside.. it works? sure but without air inside and air friction it doesnt . because the characters dont rotate wththe shipt once they jump. If you are dong multplyaer , you might not be able to use floats for your model.. Julia and other simulaton languages are using SIMD for Homogenous vecotr times like Vector2 and Vectorr4 even with posit types. Net 7 is great but lacks those stll. longs and fixed ponts and multiple CS will be fne though, and you mght work aroudn the float issue with multiple intertial frames
https://www.josstam.com/reversible

[Clonkex]

Certainly it's difficult to make physics engines play nicely with faked physics, but it's not impossible.

"I know" is the best answer I can give to everything else you mention. My multiplayer model isn't intended to be even remotely deterministic. I don't think any major games rely on determinism these days (except perhaps some RTS games); it's just too hard to do reliably, and failures in determinism are hard to recover from gracefully. Better to not expect it.

I do intend to have air pressure simulation and I have considered flow fields for pushing objects around in the case of sudden depressurisation, but it's a vague and long-term idea. I'd like to get the foundation working first :) You know, MVP and all that.

[damian-666]

You cna stick a sparse velocity field in the ship.. Not even doing full panel drag...getting into eulerian grids pressure solvers, robotic locomotion and w impure chimera methods even in 2d has taken me and a small crew 10+ plus years but I've shipped a powered ragdoll game with 30000 Brazilian fans at.one point....yea you gotta be practical

…

On Thu, Dec 1, 2022, 9:24 PM David ***@***.***> wrote: Certainly it's difficult to make physics engines play nicely with faked physics, but it's not impossible. "I know" is the best answer I can give to everything else you mention. My multiplayer model isn't intended to be even remotely deterministic. I don't think any major games rely on determinism these days (except perhaps some RTS games); it's just too hard to do reliably, and failures in determinism are hard to recover from gracefully. Better to not expect it. I do intend to have air pressure simulation and I have considered flow fields for pushing objects around in the case of sudden depressurisation, but it's a vague and long-term idea. I'd like to get the foundation working first :) You know, MVP and all that. — Reply to this email directly, view it on GitHub <#246 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD74XGPKWKTC4NVQOFQ6PBTWLFTVBANCNFSM6AAAAAASRICOJA> . You are receiving this because you commented.Message ID: ***@***.***>