PhotonDust - Fixed timestep simulation mode

[BlueCyro]

Is your feature request related to a problem? Please describe.

Currently, particle systems will attempt to simulate up to the client's framerate which can vary depending on the conditions the world.

As it stands, some particle systems that rely on things like RadialForce or turbulence (essentially anything that does a continuous change that depends on the simulation's delta time) behave very poorly when significantly long timesteps are introduced to the simulation - as-is the case when avatars spawn in, inspectors are opened, or any number of unpredictable sources of lag.

When timesteps become large enough, certain delta-dependent modules will cause the simulation to become rather unstable, often undesirably flinging particles about or causing unsightly skips.

Notable examples where lagspikes cause the simulation to become unstable include:

• When turbulence is used to create swirling patterns: Particles will deviate, move jaggedly, or even fling themselves about until the simulation settles again
• When radial force modules are used: Particles can often phase through the strongest parts of the field, or (in the case of making particles orbit) cause the particles to fling themselves away or into the center of the radial force and fly off extremely far depending on the radial force setup.

Attached is a short video demonstrating a simulated lag spike causing long-lived particles in the influence of radial effectors and turbulence to completely break down. As you can see, the simulation becomes unstable for a prolonged period of time until the particles settle once more.

2025-01-14.03-55-53.mp4

Describe the solution you'd like

I would like the ability to enable a "fixed timestep" mode on the particle system.

This could be as simple as a nullable integer which, when used, would change the behavior of the simulation from a variable timestep to a constant one, using an accumulator to keep the simulation rate constant by performing more or less steps depending on the client's framerate. The accumulator can also optionally be used to interpolate between simulation steps in order to preserve much of the fluidity of the simulation if the set framerate is below the client framerate. This would be an option that is configurable on a per-system basis.

Fixed timestep simulations have the advantage of greatly increasing the stability and determinism of a given simulation at a given framerate due to varying the amount of steps per frame rather than the amount the simulation compensates for a given frametime. This means that any hitches in the client framerate would not affect values in the simulation, thus leading to much increased stability and mitigation/elimination of the issues cited above. These benefits would be very useful for particle systems where the exact behavior is essential to a given visual effect. As it stands currently, it's easy to ruin certain effects when performance momentarily falters.

This would also allow users to specify that their particle systems should run at a lower constant framerate, allowing performance to be saved should the user deem that they don't need to simulate their system as fast as possible. Tangentially, this would also allow a certain degree of stylization to be achieved by making particle systems run at something like 10 or 15 FPS for a "retro" style or similar.

This does also introduce the ability for runaway conditions however, wherein large lagspikes cause a large number of simulation steps, which causes more lag, and eventually an infinite loop of timesteps. This can be mitigated by adding an optional user-configurable bound for how many simulation steps can occur in a single frame.

Even with the cited issue, I believe that if the user can verify that their particle system won't be prone to a runaway condition, the option to run a given particle system on a fixed timestep should be available for situations where exceptional stability in the simulation would be desired - or as-mentioned previously, for saving performance or adding stylization.

Describe alternatives you've considered

• Reconfiguring the particle system modules

  • Adding things like increased drag or turning down the strength of a given module significantly deviates from the desired effect. This can sometimes marginally increase stability, but often at the cost of the desired look of the particle.

• Wait for performance to be better

  • Once we move to .NET 9 or higher, many performance issues with photondust will be solved. However, there are always going to be sources of lag, and perfect performance can't necessarily be guaranteed or relied upon in every single scenario. Any deviation in performance will affect the system.

• Use alternative effects built by-hand with protoflux, or use alternative methods to achieve similar effects like blendshape animations

  • This negates many of the performance benefits and ease-of-use of using photondust for particles.

Additional Context

With the above said, I've been making some very cool effects with photondust thus far, but it's always made me a little sad that these effects are often marred by sessions with poor performance, or by certain viewers having worse performance (and thus a completely exploded particle system) due to large lagspikes on their end - which is why I made this feature request. Something like this would go a long way into fixing that problem.

Requesters

Myself