Physics Based Air Throws

[VMSolidus]

Description

I've made it so that when a room is explosively depressurized(or when a body of high pressure air flows into one of lower pressure air), that entities inside are launched by the air pressure with effects according to their mass. An entity's mass is now used as an innate resistance to forced movement by airflow, and more massive entities are both less likely to be launched, and will launch less far than others. While lighter entities are launched far more easily, and will shoot off into space quite quickly! Spacing departments has never been so exciting! This can be made extraordinarily fun if more objects are given the ability to injure people when colliding with them at high speeds.

As a note, Humans are very unlikely to be sucked into space at a typical force generated from a 101kpa room venting into 0kpa, unless they happened to be standing right next to the opening to space when it was created. The same cannot be said for "Lighter-Than-Human" species such as Felinids and Harpies. I guess that's just the price to pay for being cute. :)

On a plus side, because the math behind this is simplified even further than it was before, this actually runs more efficiently than the previous system.

TODO

Nothing, this is basically done. I've spent a good 6 hours straight finely tuning the system until I was satisfied that it reflects something close to reality.

MEDIA

Before the Space Wind Rework:

before.space.wind.mp4

With this Rework:

Physics.Air.Throws.mp4

Changelog

🆑 VMSolidus

• add: Atmospheric "Throws" are now calculated using object mass, and behave accordingly. Tiny objects will shoot out of rooms quite fast!

[Pspritechologist]

Certainly very impressive, and I like the effect a lot. I am concerned by the sheer number of variables being discarded (I didn't even note them all!). Even if we feel they aren't required here, they also may just be unused now, and modifying them may not have the implied effect.

Any idea why the items on the table to the left of the breach in the video seem to be unaffected, while things much further away in the room are blasted?

Finally, could we get a before clip recorded of vaguely the same view?

[VMSolidus]

Certainly very impressive, and I like the effect a lot. I am concerned by the sheer number of variables being discarded (I didn't even note them all!). Even if we feel they aren't required here, they also may just be unused now, and modifying them may not have the implied effect.

Any idea why the items on the table to the left of the breach in the video seem to be unaffected, while things much further away in the room are blasted?

That one's an interesting thing to look at. Since objects can only be moved if the force of the air flow is greater than the square of their mass, objects that are lightweight are pulled from farther away(If you look at the top right, you can see that the pens from the Dev medbay were transported all the way from medical to the hole), while objects that are heavier need to be relatively close. The force being applied scales inversely with distance, and the size of the hole in question has an effect on how much force can be applied. The C4 made a very large hole, which in turn spread the force out over a much wider area. The heavier steel on the left wasn't affected because the force wasn't great enough.

I've also noticed that the relative geometry of the hallways leading up to the hole have their own effects on the airflow.

[VMSolidus]

I haven't actually removed the variables from the system, reasoning that someone may inevitably try to use them. But they were all either Constants or CVars, not really true math variables. I'm actually not modifying any variables that get passed back, just usingh what information was already available to the function via its access to PhysicsComponent. Another function elsewhere already derives the force of a pressure differential. I did however need to keep some of the exit conditions, because technically the equation I have replaced this with is a parametric equation, it must have some form of limit.

Actually, now that you mention it, because I am dividing by true variables and not constants, I now need to go back and address potential divide by zero exits.

[VMSolidus]

Before.-.Made.with.Clipchamp.mp4

After.-.Made.with.Clipchamp.mp4

[VMSolidus]

Psprite don't merge this yet, I have a pretty good idea how I'm going to reimplement the speed clamp. It basically just means I need to test constants. In ApplyLinearImpulse(uid, vector, physicscomponent), vector is given in the form r(costhetai + sinthetaj), and in this case dirVec is a vector based on an r=1 circle, and moveForce is my value for r. I simply need to replace these two uses of moveForce with Math.Clamp(moveForce, 0, constant)

And then brute force test constants in a dev environment until I find one where it's impossible to fling a sheet of paper through a steel wall.

[rosieposieeee]

hahahahahaha this fucking rules, oh my god

bit odd that the mouse and the urist arent affected, though

[VMSolidus]

Okay! I've added the clamp back in, and did some rather extreme limit testing to determine that this actually is a good number to set the velocity limit to, which is to say it cannot exceed 30 meters per second of acceleration.

[VMSolidus]

This is now ready for some excellent reviews.

[DangerRevolution]

pog

[VMSolidus]

While examining the equations, I figured out another small optimization. Physics components contain an Inverse Mass, equal to 1/Mass. Since multiplication runs faster than division, I can make a small optimization to the equation by multiplying by InvMass instead of dividing by Mass, achieving the same result faster. Since this is a physics system that runs hundreds of times per tick, every small improvement matters a lot.

Getting rid of the division sign means its also no longer possible to divide by zero, so we no longer need to check if mass is 0 to prevent division by zero errors.

[DEATHB4DEFEAT]

I can't really say much but this is cool

[VMSolidus]

I've added a Before and After video demonstration to this PR, showing what exactly has been changed.

[Pspritechologist]

A solution needs to be thought of to prevent human-mobs from being untouched. The realism of it is quite unimportant- people need to be able to get flung into space.

This could be making the amount that mass impacts diminishing so that very heavy things can still be flung, or it could be giving mobs Components to change how they're impacted by depressurization.

[VMSolidus]

A solution needs to be thought of to prevent human-mobs from being untouched. The realism of it is quite unimportant- people need to be able to get flung into space.

This could be making the amount that mass impacts diminishing so that very heavy things can still be flung, or it could be giving mobs Components to change how they're impacted by depressurization.

I will outright refuse this Psprite because that is extremely, ridiculously out of scope for this PR, because it would necessitate completely rewriting how air flow is calculated in the first place. The original system literally just generated a random number and then used that random number to decide if a human was to be thrown. As a stopgap for the equations for air flow simply being not up to par.

[VMSolidus]

A solution needs to be thought of to prevent human-mobs from being untouched. The realism of it is quite unimportant- people need to be able to get flung into space.

This could be making the amount that mass impacts diminishing so that very heavy things can still be flung, or it could be giving mobs Components to change how they're impacted by depressurization.

Additionally, I attempted solutions in testing for creating a stopgap to throw humans more consistently, and it had run into many of the same problems the original creator did, where if even the tiniest of player character throws happened, it made the game feel extremely awful to play due to the system constantly wresting control from the player. Fixing that is also out of scope for this PR.

stale

[VMSolidus]

This is ready for review. @DEATHB4DEFEAT @Pspritechologist @DangerRevolution @Peptide90 @OldDanceJacket

[Aidenkrz]

I believe when we last talked about this, the maxvelocity cvar wasn't working correctly, and you were going to reimplement it after changing up some of the math as it currently does nothing.

[VMSolidus]

I believe when we last talked about this, the maxvelocity cvar wasn't working correctly, and you were going to reimplement it after changing up some of the math as it currently does nothing.

Thanks for the reminder, re implementing the max velocity was actually pretty easy.

[VMSolidus]

I believe when we last talked about this, the maxvelocity cvar wasn't working correctly, and you were going to reimplement it after changing up some of the math as it currently does nothing.

Actually, do you mind passing me your improvements to TileRipping? I'd like to bring them here if they work well enough there.

[Aidenkrz]

Actually, do you mind passing me your improvements to TileRipping? I'd like to bring them here if they work well enough there.

Already deleted the branch, it was pretty terrible code that I just threw together in five minutes for a proof of concept.
IIRC essentially all i did was add a counter that ticked up from the start of it being called, multiply it by a random float, and then multiply the delta by that.

[DangerRevolution]

Going to play around with this pre-review; while I do like the DS14 version, still worth testing. This should be held off from merging until @DEATHB4DEFEAT and/or @Pspritechologist review it too due to the importance/scale :)