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

Fix setting particle size #241

Merged
merged 7 commits into from
Feb 17, 2021
Merged

Fix setting particle size #241

merged 7 commits into from
Feb 17, 2021

Conversation

iche033
Copy link
Contributor

@iche033 iche033 commented Feb 10, 2021

Summary

Setting the size of the particles after the particle emitter is created had no effect. The solution is to destroy and recreate the particle system with the new size.

I also updated the code so that the ParticleEmitter class does not create all different types of particle emitters (e.g. point, box, ellipsoid, etc) when it's initialized. When the user changes the emitter type, we'll destroy the existing emitter and create a new one with the specified type.

Note: my original intention was to have a flag to mark the emitter as dirty when the above params changed and let PreRender() handle the recreation of the emitter. However it was found that overriding PreRender() broke ABI so I worked around it with a manual PreRenderImpl call

Checklist

  • Signed all commits for DCO
  • Added tests
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • codecheck passed (See
    contributing)
  • All tests passed (See
    test coverage)
  • While waiting for a review on your PR, please help review
    another open pull request
    to support the maintainers

Note to maintainers: Remember to use Squash-Merge

Signed-off-by: Ian Chen <ichen@osrfoundation.org>
Signed-off-by: Ian Chen <ichen@osrfoundation.org>
Signed-off-by: Ian Chen <ichen@osrfoundation.org>
@iche033 iche033 marked this pull request as draft February 10, 2021 04:58
@github-actions github-actions bot added the 🔮 dome Ignition Dome label Feb 10, 2021
@osrf-triage osrf-triage added this to Inbox in Core development Feb 10, 2021
@chapulina chapulina moved this from Inbox to In progress in Core development Feb 10, 2021
Signed-off-by: Ian Chen <ichen@osrfoundation.org>
@codecov
Copy link

codecov bot commented Feb 12, 2021

Codecov Report

Merging #241 (a84dbbf) into ign-rendering4 (20d6471) will increase coverage by 0.28%.
The diff coverage is 68.39%.

Impacted file tree graph

@@                Coverage Diff                 @@
##           ign-rendering4     #241      +/-   ##
==================================================
+ Coverage           52.59%   52.87%   +0.28%     
==================================================
  Files                 143      143              
  Lines               13329    13563     +234     
==================================================
+ Hits                 7010     7172     +162     
- Misses               6319     6391      +72     
Impacted Files Coverage Δ
include/ignition/rendering/ArrowVisual.hh 100.00% <ø> (ø)
include/ignition/rendering/AxisVisual.hh 100.00% <ø> (ø)
include/ignition/rendering/Camera.hh 100.00% <ø> (ø)
include/ignition/rendering/CompositeVisual.hh 100.00% <ø> (ø)
include/ignition/rendering/Geometry.hh 100.00% <ø> (ø)
include/ignition/rendering/Image.hh 100.00% <ø> (ø)
include/ignition/rendering/Light.hh 100.00% <ø> (ø)
include/ignition/rendering/Material.hh 100.00% <ø> (ø)
include/ignition/rendering/Mesh.hh 100.00% <ø> (ø)
include/ignition/rendering/Node.hh 100.00% <ø> (ø)
... and 44 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ecdb5a3...a84dbbf. Read the comment docs.

@iche033 iche033 marked this pull request as ready for review February 12, 2021 07:40
Copy link
Contributor

@adlarkin adlarkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

Update: Take a look at my comment below that follows up on my initial testing remarks here.

I would like to update the particle emitter test. Right now, the current test creates a particle emitter, checks to make sure it was created properly, modifies all particle emitter properties, and then checks the newly modified emitter to make sure that everything was update correctly. I think that we should add a test case where we create an emitter, but then modify only the type and then only the particle size. That way, we can make sure that all of the other properties of the emitter are still correct if only the type and/or particle size is modified. @iche033 I can take care of updating this test if you'd like (just let me know!).

Comment on lines +123 to +136
// area emitter
ParticleEmitterPtr areaEmitter = _scene->CreateParticleEmitter();
areaEmitter->SetType(EM_BOX);
areaEmitter->SetEmitterSize({3.0, 3.0, 3.0});
areaEmitter->SetLocalPose({3, 0, 0, 0, -1.5707, 0});
areaEmitter->SetRate(10);
areaEmitter->SetParticleSize({0.01, 0.01, 0.01});
areaEmitter->SetLifetime(1);
areaEmitter->SetVelocityRange(0.5, 1);
areaEmitter->SetMaterial(particleMaterial);
areaEmitter->SetColorRangeImage(RESOURCE_PATH + "/smokecolors.png");
areaEmitter->SetScaleRate(1);
areaEmitter->SetEmitting(true);
root->AddChild(areaEmitter);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the tutorial need to be updated at all to make reference to this new area emitter?

ogre2/src/Ogre2ParticleEmitter.cc Show resolved Hide resolved
ogre2/src/Ogre2ParticleEmitter.cc Outdated Show resolved Hide resolved
ogre2/src/Ogre2ParticleEmitter.cc Show resolved Hide resolved
ogre2/src/Ogre2ParticleEmitter.cc Outdated Show resolved Hide resolved
ogre2/src/Ogre2ParticleEmitter.cc Outdated Show resolved Hide resolved

this->SetEmitterSize(this->emitterSize);

// set other properties
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we need to call SetDuration and SetEmitting here as well, since these methods set properties for this->dataPtr->emitter.

Copy link
Contributor

@adlarkin adlarkin Feb 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added in a19125e. @iche033 if this looks good to you, feel free to mark this as resolved.

ogre2/src/Ogre2ParticleEmitter.cc Outdated Show resolved Hide resolved
@adlarkin adlarkin self-assigned this Feb 12, 2021
Signed-off-by: Ashton Larkin <ashton@openrobotics.org>
@adlarkin
Copy link
Contributor

I went ahead and addressed some of my feedback in a19125e.

I wanted to follow up about my previous comment regarding tests. So, it looks like the particle emitter unit test tests the data members that belong to the BaseParticleEmitter class, but what we should really do here is add a test to ensure that the Ogre::ParticleEmitter object in the Ogre2ParticleEmitter class is being updated correctly whenever an emitter is re-created due to a type or particle size change. Is it possible to test the validity of this data member somehow, or is it impossible since this data member belongs to Ogre2ParticleEmitterPrivate?

@iche033 iche033 mentioned this pull request Feb 12, 2021
@iche033
Copy link
Contributor Author

iche033 commented Feb 12, 2021

Is it possible to test the validity of this data member somehow, or is it impossible since this data member belongs to Ogre2ParticleEmitterPrivate?

I'm trying to keep the tests generic so we can run them for different rendering engines. The other option is an integration test to test before and after changing type or particles, e.g. if you have a point particle emitter with a duration or 1 sec and then you change it to a box emitter, you should see the particles more spread out while only being enabled for 1 sec as well.

@adlarkin
Copy link
Contributor

I'm trying to keep the tests generic so we can run them for different rendering engines.

Good point, I didn't think about that 👍

The other option is an integration test to test before and after changing type or particles, e.g. if you have a point particle emitter with a duration or 1 sec and then you change it to a box emitter, you should see the particles more spread out while only being enabled for 1 sec as well.

That's not a bad idea. The only thing to consider with an integration test like this is that we should try to test all of the emitter properties, not just duration (particle size, velocity, scale rate, etc.), which I think would be very difficult to test. So, we can either write an integration test that checks for some of these things, or just leave everything as-is (i.e., just keep the unit test). I'm not sure what would be better.

@iche033
Copy link
Contributor Author

iche033 commented Feb 16, 2021

I'm leaning towards keeping the test as is given the amount of effort needed and time to get other particle effects changes in. Let's revisit this in the future. I've ticked an issue: #249

@adlarkin
Copy link
Contributor

Most of this looks good to me, but before merging, @iche033 can you take a look at my feedback/review comments above and changes I made in a19125e? In particular, I'd like to get your confirmation about this change. If all the changes look good to you, then I am okay with approving and merging this.

@iche033
Copy link
Contributor Author

iche033 commented Feb 16, 2021

If all the changes look good to you, then I am okay with approving and merging this.

the changes look good, thanks!

Core development automation moved this from In progress to In review Feb 16, 2021
@adlarkin adlarkin merged commit 938e42c into ign-rendering4 Feb 17, 2021
Core development automation moved this from In review to Done Feb 17, 2021
@adlarkin adlarkin deleted the particle_size branch February 17, 2021 00:19
@j-rivero j-rivero removed this from Done in Core development May 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants