-
Notifications
You must be signed in to change notification settings - Fork 51
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
Particle emitter - part3 #117
Conversation
Signed-off-by: Carlos Aguero <[email protected]>
Signed-off-by: Carlos Aguero <[email protected]>
Signed-off-by: Carlos Aguero <[email protected]>
Signed-off-by: Ian Chen <[email protected]>
I made some changes in 2eb5cc2. Materials / textures should work now. |
looked a little bit into loading |
Signed-off-by: Carlos Aguero <[email protected]>
This reverts commit e9ba80a.
Signed-off-by: Carlos Aguero <[email protected]>
I created a minimum example in the
Here's extra info:
Maybe I'm using it wrong... |
It seems that the affectors are supposed to be used in a different way. See the next block:
(Using the base class with |
I think I figured it out, I'll update the PR with new changes. |
Signed-off-by: Carlos Aguero <[email protected]>
Signed-off-by: Ian Chen <[email protected]>
Signed-off-by: Carlos Aguero <[email protected]>
@iche033, all API calls should be implemented in Ogre2 now. Could you take another look please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good! Just a comment about setting type. Others are minor
/// the image is used. | ||
/// \param[in] _image The color image name. | ||
/// \sa ColorImage | ||
public: virtual void SetColorImage(const std::string &_image) = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about calling this SetColorRangeImage
. It's doing something very similar to SetColorRange
but from an image. Another reason is to avoid confusion with setting the actual particle texture that they supplied when calling SetMaterial
I also noticed that this overrides SetColorRange
and vice versa depending on which function is called last. Maybe we can add that to the documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense. It would even make more sense to overload the functions but C++ doesn't allow us to overload two functions just based on the return value :/ 571a08f.
ogre2/src/Ogre2ParticleEmitter.cc
Outdated
public: Ogre::ParticleEmitter *emitter = nullptr; | ||
|
||
// \brief Ogre colour image affector. | ||
public: Ogre::ParticleAffector *colourImageAffector = nullptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we keep spelling consistent with others in ign? i.e. colour
-> color
. No strong opinion here since the public API uses color
which is consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 571a08f. We have to be careful with the strings passed to Ogre because they need to be "colour"
.
ogre2/src/Ogre2ParticleEmitter.cc
Outdated
{ | ||
case EmitterType::EM_POINT: | ||
{ | ||
this->dataPtr->ps->removeAllEmitters(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think with the remove call here, calling SetType
will remove existing emitter settings, e.g. size, duration, rate, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that was a bug, good catch. Fixed in 571a08f.
In order to make it work, we now keep an array of emitters, one of each supported type. When an attribute is set, we set it in each emitter but only one is visible at a time. When the function SetType()
is called we switch to the appropriate emitter.
Signed-off-by: Carlos Aguero <[email protected]>
I think this is ready for prime time, I'm removing the draft part. Maybe I can create a tutorial in another PR. |
Signed-off-by: Ian Chen <[email protected]>
made a couple of updates in fa3c8e4
|
There are a couple of expectations failing when running the test with
I think it is failing because the values are invalid and so they are never set. Could you take a look? |
Signed-off-by: Carlos Aguero <[email protected]>
Thanks! |
Fixed in 9ac9812. |
Signed-off-by: Ian Chen <[email protected]>
there is a minor issue with DCO, otherwise looks good! |
Here's the particle implementation for Ogre2.
Open questions:
SetMaterial(): Right now, we create an
unlit
internal material because this is the type that seems to work with the particle system. Then, when we callParticleEmitter::SetMaterial()
we should copy some of the properties of the material. I think Unlit and PBS don't share the same attributes. Should we copy the common ones? Maybe at least the texture?Reference: https://ogrecave.github.io/ogre/api/2.1/class_ogre_1_1_hlms_unlit_datablock.html
This PR doesn't implement the
SetType()
andSetEmitterSize()
yet because the default particle emitters are contained inside theParticleFX
Ogre2 plugin. I don't think our FindIgnRendering for Ignition CMake is ready to use this plugin. Did anyone has experience usingParticleFX
?How to test it? Compile the
particles_demo
example and run it. You should see something similar to this: