Bug / Crash Fluid emitter stuttering with more fixed steps and lower FPS

[josemendez]

Hi Nyphur!

Thanks for your kind words, they're really appreciated .

There's 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.

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?

The exact point at which simulation and rendering happen depend on the solver's synchronization mode. By default, Obi uses asynchronous mode which renders the previous frame, then kicks off simulation of the current frame. This allows an entire frame worth of time for the simulation to be completed before the main thread has to wait for its results, which yields the best performance. However, rendering is always 1 frame behing physics state. Check the new page for update loop / timesteps as it also explains this: http://obi.virtualmethodstudio.com/manua...eloop.html

You can switch to synchronous mode. This is considerably costlier as it forces the frame's simulation to finish before rendering, but the current frame's state is rendered instead of the previous one.

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.

That's not entirely accurate: the amount of particles emitted per frame depends on the ratio between the velocity of the emitted particles and their size: at the start of each step the distance the previously emitted particles have moved forward is calculated and divided by the size of a particle, this yields the amount of particle "bursts" that need to be emitted and the distance from the emitter that they should be spawned at.

So the distance between particles should be constant regardless of the amount of time steps performed during the frame. Will test this and get back to you, if it doesn't work as expected there might be a bug.

kind regards,