Atmos Delta-Pressure Window Shattering

[ArtisticRoomba]

About the PR

This PR adds delta-pressure damage. In short, airtight structures can now take damage proportional to the difference in pressures between the sides of the structure.

Why / Balance

This is a desired feature in the Atmos Roadmap.

The horror factor of overpressure is very real - right now you can just sit behind a reinforced glass pane with a roaring plasmafire and stay in your room. Now if the glass pane started to crack, and groan? You'd be scared shitless. I think it would contribute very well to the horror element of SS14.

It partially limits atmospheric technicians, forcing them to work in dedicated burn chambers or structures where their burns can hold pressure. This means that you can't just go pedal-to-the-medal, rather you'll have to manage your chamber pressure carefully. This also kills mini burn chambers - atmos techs will have to use the burn chambers they're provided or find a way to reinforce their mini burn chambers.

Technical details

This is put up primarily for code review on the processing side - the constants are not tuned yet and other misc stuff like CVARs and AtmosTime modifications are not implemented yet (though easy to do, I just wanted to write this).

Entities that want to take pressure damage need to have a DeltaPressureComponent that defines the damage and at what pressure, as well as the scaling type.

A new processing mode has been added, DeltaPressure.

Atmospherics will process entities that need to be calculated via a queue.
Entities will automatically add and remove themselves from the hashset that stores these entities on the GridAtmosComponent for processing.

When an entity is dequeued for processing:

• The entity's tile indices position is retrieved
• This is used to get the TileAtmospheres around the entity
• The pressures of these TileAtmospheres are split into anti-directional pairs and loaded into a span to do SIMD calculations using helper methods in NumericsHelpers
• The delta-pressure is then computed from this and damage is done from the entity based on that

A good chunk of the slowdown is from the retrieval of elements from the dictionary, as well as retrieval of the actual pressure from the tile (as we have to call a GasMixture get method). I might take a crack at implementing a proper cache however my last attempt at this yielded no measurable performance improvement, though I might try again.

Media

Screencast_20250726_234154.mp4

Screencast_20250725_001832.mp4

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Not really any. Anyone who's implemented any custom processing loops downstream will have to consider this one.

Changelog
🆑

• add: Added atmospherics delta-pressure structure damage. Objects like windows, thindows, windoors, etc. will have damage done to them depending on the pressure difference across the sides of the object.

[VerinSenpai]

Roomba fucking strikes again 🫡

[ArcaneOcto]

bro atmos has been eating lately

[VerinSenpai]

bro atmos has been eating lately

I'm full, but also fat. Keep it coming

[PunishedJoe]

https://www.youtube.com/watch?v=joZEhXQK9ew

[EthanQix]

Since the pressure delta is calculated from opposite sides of the object, does this mean a double layer window/thindow is functionally pressure immune ?

[K-Dynamic]

I'm not sure if this will kill mini-burn chambers since they may just use steel walls instead

[VerinSenpai]

Not that I have the slightest clue how it would be implemented, though I do think itd look better if all the glass didn't change states at once.

[PubliclyExecutedPig]

wont this break things like this on oasis or am i missing something?

[ScarKy0]

wont this break things like this on oasis or am i missing something?

The point is to make atmos techs make their burn chambers smarter instead of pumping as much pressure into them as possible

[VerinSenpai]

A better thing to ask would be at what point do things start breaking. What's the minimum difference they can take.

[ArtisticRoomba]

Tests and benchmark rolled into this PR at request

[Partmedia]

This should not be a magic number, or at least this should match the default in the component, which is also a magic number currently set at 50. I have also said this multiple times, but 10 or 50 sound way too small. Can you profile this and determine what a "good" batch size is?

I have also said multiple times that this needs to be plotted against the number of parallel jobs on the x axis, not the number of entities. We already know it scales linearly with the number of entities.

[Partmedia]

(Also not a blocking issue -- it's good enough that we have a benchmark in the first place.)

[ArtisticRoomba]

Let me go ahead and do some more profiling now that I have a better understanding of what we're looking for

[Partmedia]

Just to be clear -- we are trying to use profiling to determine the best batch size and iteration size for a representative but high-ish end of entities, e.g. the number of entities that you can reasonably expect on a large map x2.

[ArtisticRoomba]

So, I'm doing more profiling but I'll at least show what I've got so far: a really, really, shit chart. Sorry you have to look at it. But it does give us insights, and I'll get some more soon. All graphs are for PerformFullProcess.

Bear with me:

• The series represents how many entities are being submitted for processing per run.
• Ignore the datapoints beyond X = 5000, as that indicates Entities => BatchSize, AKA single thread performance.
• You can see that if we submit not enough entities to process in a loop iteration our performance gets reduced to single-threaded equivalents.
• If we submit the same amount of entities that we process in a batch, performance gets reduced to single-threaded equivalents.

This is a similar case for processing 100,000 entities:

[Partmedia]

Thank you for doing this.

So, if I'm interpreting this correctly, it seems like a (small to me) batch size of 10 is actually the optimal batch size? If so, we should set the default to that.

I would still be curious in seeing how performance changes with respect to the number of parallel jobs. But that can be done at a later time.

[ArtisticRoomba]

Default set. Still scratching my head on the parallelism speedup in general, but I'll probably spend some time reading up on it later.

[Partmedia]

The fact that it clamps at 50 here is not documented anywhere. I can suggest removing this and relying entirely on the CVar.

[Partmedia]

Also, the name of this variable is confusing because BatchSize is the name of a CVar that does something slightly different.

[Partmedia]

This comment still doesn't inform how I as a server operator should set this. Is this the number of entities per parallel job? What exactly happens if each parallel job finishes at a different time? Is this checked at the end of each job that finishes, or after all parallel jobs finish?

[Partmedia]

If the goal is to avoid exceeding a tick limit, this is not how the global process per iteration should work, because the behavior would be wildly different on a box with 2 cores vs 64 cores. Instead:

N = // number of entities to process
cores = // number of parallel jobs
entitiesPerCore = N / cores;
// make sure entitiesPerCore is not lower than some number, that you will determine in benchmarking
// start parallel jobs with entitiesPerCore, which may be smaller than the actual number of cores. This is fine, because for small sizes the overhead of multithreading doesn't make multithreading worth it and this handles this case automatically

[Partmedia]

I think this is good enough for now. There are still opportunities for improvement, and there are still issues that are marked "resolved" that could use some improvement, but I think it is time to get this in and evaluate based on the gameplay. We can spend a long time getting code perfect, but it's time to get this to players.

I am not merging to give you a chance to get in any final minor changes, then please self-merge.