Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential non-deterministic behavior in particle emitter (ogre2) #556

Open
iche033 opened this issue Feb 8, 2022 · 5 comments · Fixed by #584
Open

Potential non-deterministic behavior in particle emitter (ogre2) #556

iche033 opened this issue Feb 8, 2022 · 5 comments · Fixed by #584
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@iche033
Copy link
Contributor

iche033 commented Feb 8, 2022

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 iche033 added the bug Something isn't working label Feb 8, 2022
@darksylinc
Copy link
Contributor

darksylinc commented Feb 14, 2022

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.

@chapulina chapulina added the help wanted Extra attention is needed label Mar 1, 2022
darksylinc added a commit to darksylinc/ign-rendering that referenced this issue Mar 12, 2022
This fixes Particle FXs not respecting simulation time
Fixes gazebosim#556

Signed-off-by: Matias N. Goldberg <[email protected]>
darksylinc added a commit to darksylinc/ign-rendering that referenced this issue Mar 26, 2022
This fixes Particle FXs not respecting simulation time
Fixes gazebosim#556

Signed-off-by: Matias N. Goldberg <[email protected]>
darksylinc added a commit to darksylinc/ign-rendering that referenced this issue Mar 26, 2022
This fixes Particle FXs not respecting simulation time
Fixes gazebosim#556

Signed-off-by: Matias N. Goldberg <[email protected]>
darksylinc added a commit to darksylinc/ign-rendering that referenced this issue Mar 26, 2022
This fixes Particle FXs not respecting simulation time
Fixes gazebosim#556

Signed-off-by: Matias N. Goldberg <[email protected]>
darksylinc added a commit to darksylinc/ign-gazebo that referenced this issue Mar 27, 2022
darksylinc added a commit to darksylinc/ign-rendering that referenced this issue Apr 3, 2022
This fixes Particle FXs not respecting simulation time
Fixes gazebosim#556

Signed-off-by: Matias N. Goldberg <[email protected]>
darksylinc added a commit to darksylinc/ign-gazebo that referenced this issue Apr 3, 2022
iche033 pushed a commit that referenced this issue Apr 4, 2022
* Use custom simulation time variants for Ogre

This fixes Particle FXs not respecting simulation time
Fixes #556

Signed-off-by: Matias N. Goldberg <[email protected]>
@darksylinc
Copy link
Contributor

darksylinc commented Apr 4, 2022

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

@iche033
Copy link
Contributor Author

iche033 commented Apr 4, 2022

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

@iche033 iche033 reopened this Apr 4, 2022
@darksylinc
Copy link
Contributor

I've pushed OGRECave/ogre-next@d3bd8b4 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.

@iche033
Copy link
Contributor Author

iche033 commented May 5, 2022

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, #553.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants