!rant

so i've been playing around with this idea for some time... a relative reference frame physics engine.

why?
because in short, if it's not completely stupid (which I'm still not sure), and if it would work how I think it should/would, then it would solve most (if not all) problems current physics engines have with moving inside/on moving objects (which are inside/on other moving objects)...

...anyone reading this has at least a slight idea what I mean/am thinking about?

Problem: when your subject moves, you'd have to move the entire world around it instead. If we assume that the entire world around your subject requires a lot more vertices to be defined, that would mean updating the position of many more objects at the same time for each step of your simulation, thus lowering performance. (But I'm just spitballing assumptions here, I could be wrong)

From a physical perspective, the two solutions would be equivalent, and I'm not quite sure how your implementation would solve the issue you mentioned: wouldn't you just be moving the problem from one place to another?

@endor

no, not that. well, afaik, Kerbal Space Program does it like that, they wrote in some devlog that "trick number XYZ: don't move the player - move the world", so apparently it is a viable option.

but that's not what I meant, what I meant is in relation to forces. imagine you're standing in a bus, right now, how you move is that the bus moves and through drag and you being in contact with the bus, part of that force transfers to you to move you along.

but what if I said "you're IN the bus, so your transform is childed under the bus, so however bus changes position, you also immediately change position to keep your relative position to the bus the same, *then apply the maximum force in the opposite direction (basically inertia) until point where collision happens, then apply remaining force as a deformation/damage force for the player*

@endor so now you could do boxes in boxes in boxes in which is the player, and rattle it around however, and the physics would be pretty much stable all the time, no warping through each other, no stupid "RigidbodyFPSController elevator problem" and basically this whole family of instability issues of motion on/within moving object would be solved... i think?

well ok i probably oversold the idea in the OP, but i think it could still solve a nice large set of issues which are currently common.

@Midnight-shcode I think most current engines don't like applying forces to everything. A large number of forces is a massive performance hit. But that doesn't mean you can't make an engine specifically with that in mind.

Isn't this what Unity does? I mean, by default children follow parents around. You would just need a component that applies the node's acceleration and torque as forces to it's children.

@Lor-inc by default they do, yes. but as soon as you attach physics components to objects, that kind of seems to take them out of the hierarchy, and changes all their movement to be global, I think. tbh i never actually checked, but from what i've seen while working with the system, I don't think it does this, otherwise i think it wouldn't have the issues that I mentioned.

@Midnight-shcode I just tried, and Unity does it much, much worse. The transform is always relative, and rigidbody always affects the transform. So if you accelerate, all your children also accelerate, but if your children collide with something from the outside, by default you aren't affected. You need a joint for that, but then that joint will only transfer forces in your direction unless a collision occurs. You can't overstress the joint by accelerating yourself, only your children can.

@Lor-inc oof...
here's hoping that at least the DOTS physics system is a bit more sane