gz-rendering icon indicating copy to clipboard operation
gz-rendering copied to clipboard

Potential non-deterministic behavior in particle emitter (ogre2)

Open iche033 opened this issue 3 years ago • 5 comments

Environment

  • OS Version: Ubuntu Focal
  • Source or binary build? Affects both source and binary in all versions

Description

The particle emitter in ogre2 uses the Particle FX plugin. The plugin likely animates the particles using real time so the effect could be non-deterministic.

  • Expected behavior: Speed of particles are dependent on user-specified time steps
  • Actual behavior: Particles are animated using real time

Steps to reproduce

  1. Easier to reproduce using ign gazebo. Change <real_time_factor> in particle_emitter2.sdf file to 0 so simulation runs as fast as possible.
  2. Launch ign gazebo with the modified particle_emitter2.sdf world
  3. See the particles flow upwards in regular speed when it should be flowing as fast as possible.

iche033 avatar Feb 08 '22 00:02 iche033

I haven't looked much into this, for what is worth ParticleSystemUpdateValue register itself to update the particle, which gets called in ControllerManager::updateAllControllers and gets updated when we (ignition) directly or indirectly call updateSceneGraph (normally Ogre does that call but I think it was in Edifice that I changed it so that we call it explicitly).

I've been thinking there's two possible solutions:

  1. Somehow figure out how to manually update the controlled ourselves so we use simulation time.
  2. Modify Ogre so that Root::populateFrameEvent can alternatively be fed user-specified time (i.e. simulation time) instead of real time.

The 2nd option is highly desirable because it will also fix other stuff I just realized we were overlooking: For example any time-based postprocessing FX (if there's any, I think the gaussian noise is using it) should be using simulation time, not real time.

darksylinc avatar Feb 14 '22 14:02 darksylinc

We should either reopen this ticket or create a new one because there is still one source of non-determinism to fix:

// Ideal:
const float timeToSimulate = 10 seconds;
const int numTicks = floor( timeToSimulate / tickRate );
for( int i = 0; i < numTicks; ++i )
    updateParticles( tickRate );

// What is happening when you relaunch the GUI with a simulation of 10 seconds
const float timeToSimulate = 10 seconds;
updateParticles( timeToSimulate ); // Just one tick with 10.0 as tick rate

darksylinc avatar Apr 04 '22 22:04 darksylinc

github auto-closed the issue with the merge of #584. Reopening.

iche033 avatar Apr 04 '22 23:04 iche033

I've pushed https://github.com/OGRECave/ogre-next/commit/d3bd8b423d53b08276d7d5b4501f36160a0a25c5 to branches:

  • 2.2
  • 2.3
  • master

AFAICT it won't break ABI nor API.

By calling ParticleSystemManager::getSingleton().setSimulationTickRate( positive_non_zero_value ) as soon as possible during initialization and then setting the tick rate to the desired one at any time will do the trick.

Now the thing is getting this patch into Ignition's fork.

darksylinc avatar Apr 30 '22 17:04 darksylinc

thanks, we'll likely just have this fix in Garden with ogre 2.3. So I'll keep in mind to test this as part of the review of your existing PR, https://github.com/ignitionrobotics/ign-rendering/pull/553.

iche033 avatar May 05 '22 19:05 iche033