Before I get into my problem, I just wanted to say how amazing the new version of Obi is. Thank you so much for continuing to work on these tools, the new Compute solver is incredible and the new fluid surface mesher is pure magic. We've been able to vastly increase fluid particle numbers and visual fidelity while also massively improving performance. The main issues I've had are just getting any kind of colour and opacity out of liquids, but I've been able to tweak the shaders in shadergraph to solve that and add custom effects. Honestly, you've done some amazing work on these tools!
The problem:
The issue I'm having now is with the simulation speed and emitter particle speed in a game that runs under the fixed timestep. We're using a fixed timestep of 0.1666667 and all the sample scenes work perfectly fine because they all run above 60 FPS, but in our actual game scene our FPS often dips under 60. This causes the simulation to appear to run in slow motion because the Obi Solver is running 1 max step per frame.
When I increase the max steps per frame, the simulation appears to run at full speed because it's doing the extra catch-up steps when needed, the new docs pages about the simulation timesteps has been very useful in figuring that out. The issue is that in this circumstance, the Obi Emitters no longer emit a steady stream, the stream becomes broken up with gaps, where some frames produce more particles and some less.
There's also a visible gap at the point of fluid emission that gets worse with increased fixed steps per frame because the simulation has already moved the particles by the time the next render frame comes around. It seems that emitted particles don't get rendered until they've been through a full simulation cycle and at that point they aren't at the location they spawned in. I would have expected that emitted particles would be rendered immediately so that the precise emitter particle spawn spots are always filled and the fluid always appears to start solidly from the same location.
Possible cause and workaround:
I think the cause has to do with an instability in the number of fixed frames per rendered frame, where some rendered frames end up with 1 fixed frame and some have 2, or if you're below half the fixed timestep some will have 2 and some will have 3. Emitters can only emit particles in discrete quantities, so that naturally results in stuttering. The frames that have 3 fixed updates move the existing particles further and the ones with 2 fixed updates don't move them far enough to cause new particles to be emitted, so that leads to gaps.
Ultimately I do have to try to get the performance of the scene up, but the only solution I can think of for anyone below 60 FPS would be to forcibly lock the framerate to integer factors of the fixed timestep. So any frame rate under 60 would become 30 so it'd always be precisely 2 fixed steps per frame, and then anything below 30 would become 15. That's not ideal but it does stabilise the simulation speed as too few fixed update steps leads to slow simulation and inconsistent numbers of steps leads to gaps.
The alternative would be to use a script to dynamically set the max steps per frame depending on the frame rate so that it never goes too high. For example, a game running at 50FPS would have a max steps of 1 and the simulation would just appear to run slightly slowly, while at 25 FPS the game would have a max steps of 2 and again just appear to run slightly slowly. That might be preferable to locking the frame rate, it's a trade-off I might have to make.
Remaining questions:
Writing this out has helped me figure it out, but does this all sound right to you or could there be a bug with how emitters handle different numbers of fixed timesteps? Also particles emitted seem to undergo a full frame's simulation cycle before they're rendered, causing that visible gap at the point of emission if there's a lot of sim steps per frame occurring, is that something that you could change or is it not possible to render emitted particles until they've gone through a simulation step?
Once again, amazing toolset Jose!
The problem:
The issue I'm having now is with the simulation speed and emitter particle speed in a game that runs under the fixed timestep. We're using a fixed timestep of 0.1666667 and all the sample scenes work perfectly fine because they all run above 60 FPS, but in our actual game scene our FPS often dips under 60. This causes the simulation to appear to run in slow motion because the Obi Solver is running 1 max step per frame.
When I increase the max steps per frame, the simulation appears to run at full speed because it's doing the extra catch-up steps when needed, the new docs pages about the simulation timesteps has been very useful in figuring that out. The issue is that in this circumstance, the Obi Emitters no longer emit a steady stream, the stream becomes broken up with gaps, where some frames produce more particles and some less.
There's also a visible gap at the point of fluid emission that gets worse with increased fixed steps per frame because the simulation has already moved the particles by the time the next render frame comes around. It seems that emitted particles don't get rendered until they've been through a full simulation cycle and at that point they aren't at the location they spawned in. I would have expected that emitted particles would be rendered immediately so that the precise emitter particle spawn spots are always filled and the fluid always appears to start solidly from the same location.
Possible cause and workaround:
I think the cause has to do with an instability in the number of fixed frames per rendered frame, where some rendered frames end up with 1 fixed frame and some have 2, or if you're below half the fixed timestep some will have 2 and some will have 3. Emitters can only emit particles in discrete quantities, so that naturally results in stuttering. The frames that have 3 fixed updates move the existing particles further and the ones with 2 fixed updates don't move them far enough to cause new particles to be emitted, so that leads to gaps.
Ultimately I do have to try to get the performance of the scene up, but the only solution I can think of for anyone below 60 FPS would be to forcibly lock the framerate to integer factors of the fixed timestep. So any frame rate under 60 would become 30 so it'd always be precisely 2 fixed steps per frame, and then anything below 30 would become 15. That's not ideal but it does stabilise the simulation speed as too few fixed update steps leads to slow simulation and inconsistent numbers of steps leads to gaps.
The alternative would be to use a script to dynamically set the max steps per frame depending on the frame rate so that it never goes too high. For example, a game running at 50FPS would have a max steps of 1 and the simulation would just appear to run slightly slowly, while at 25 FPS the game would have a max steps of 2 and again just appear to run slightly slowly. That might be preferable to locking the frame rate, it's a trade-off I might have to make.
Remaining questions:
Writing this out has helped me figure it out, but does this all sound right to you or could there be a bug with how emitters handle different numbers of fixed timesteps? Also particles emitted seem to undergo a full frame's simulation cycle before they're rendered, causing that visible gap at the point of emission if there's a lot of sim steps per frame occurring, is that something that you could change or is it not possible to render emitted particles until they've gone through a simulation step?
Once again, amazing toolset Jose!
.