2012-03-22 01:36:20 +08:00
|
|
|
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
|
2003-01-22 00:45:36 +08:00
|
|
|
*
|
2012-03-22 01:36:20 +08:00
|
|
|
* This library is open source and may be redistributed and/or modified under
|
|
|
|
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
|
2003-01-22 00:45:36 +08:00
|
|
|
* (at your option) any later version. The full license is in LICENSE file
|
|
|
|
* included with this distribution, and on the openscenegraph.org website.
|
2012-03-22 01:36:20 +08:00
|
|
|
*
|
2003-01-22 00:45:36 +08:00
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
2012-03-22 01:36:20 +08:00
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2003-01-22 00:45:36 +08:00
|
|
|
* OpenSceneGraph Public License for more details.
|
|
|
|
*/
|
2002-06-05 20:44:55 +08:00
|
|
|
//osgParticle - Copyright (C) 2002 Marco Jez
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
#ifndef OSGPARTICLE_OPERATOR
|
|
|
|
#define OSGPARTICLE_OPERATOR 1
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
#include <osgParticle/Program>
|
|
|
|
|
|
|
|
#include <osg/CopyOp>
|
|
|
|
#include <osg/Object>
|
|
|
|
#include <osg/Matrix>
|
|
|
|
|
|
|
|
namespace osgParticle
|
|
|
|
{
|
|
|
|
|
|
|
|
// forward declaration to avoid including the whole header file
|
|
|
|
class Particle;
|
|
|
|
|
2012-03-22 01:36:20 +08:00
|
|
|
/** An abstract base class used by <CODE>ModularProgram</CODE> to perform operations on particles before they are updated.
|
2002-06-05 20:44:55 +08:00
|
|
|
To implement a new operator, derive from this class and override the <CODE>operate()</CODE> method.
|
|
|
|
You should also override the <CODE>beginOperate()</CODE> method to query the calling program for the reference frame
|
|
|
|
used, and initialize the right transformations if needed.
|
|
|
|
*/
|
2012-03-22 01:36:20 +08:00
|
|
|
class Operator: public osg::Object {
|
2002-06-05 20:44:55 +08:00
|
|
|
public:
|
|
|
|
inline Operator();
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Operator(const Operator& copy, const osg::CopyOp& copyop = osg::CopyOp::SHALLOW_COPY);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
virtual const char* libraryName() const { return "osgParticle"; }
|
|
|
|
virtual const char* className() const { return "Operator"; }
|
|
|
|
virtual bool isSameKindAs(const osg::Object* obj) const { return dynamic_cast<const Operator* >(obj) != 0; }
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get whether this operator is enabled.
|
|
|
|
inline bool isEnabled() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Enable or disable this operator.
|
|
|
|
inline void setEnabled(bool v);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT
type is supported at present. The attached osgparticleshader.cpp will
show how it works. It can also be placed in the examples folder. But I
just wonder how this example co-exists with another two (osgparticle
and osgparticleeffect)?
Member variables in Particle, including _alive, _current_size and
_current_alpha, are now merged into one Vec3 variable. Then we can
make use of the set...Pointer() methods to treat them as vertex
attribtues in GLSL. User interfaces are not changed.
Additional methods of ParticleSystem are introduced, including
setDefaultAttributesUsingShaders(), setSortMode() and
setVisibilityDistance(). You can see how they work in
osgparticleshader.cpp.
Additional user-defined particle type is introduced. Set the particle
type to USER and attach a drawable to the template. Be careful because
of possible huge memory consumption. It is highly suggested to use
display lists here.
The ParticleSystemUpdater can accepts ParticleSystem objects as child
drawables now. I myself think it is a little simpler in structure,
than creating a new geode for each particle system. Of course, the
latter is still compatible, and can be used to transform entire
particles in the world.
New particle operators: bounce, sink, damping, orbit and explosion.
The bounce and sink opeartors both use a concept of domains, and can
simulate a very basic collision of particles and objects.
New composite placer. It contains a set of placers and emit particles
from them randomly. The added virtual method size() of each placer
will help determine the probability of generating.
New virtual method operateParticles() for the Operator class. It
actually calls operate() for each particle, but can be overrode to use
speedup techniques like SSE, or even shaders in the future.
Partly fix a floating error of 'delta time' in emitter, program and
updaters. Previously they keep the _t0 variable seperately and compute
different copies of dt by themseleves, which makes some operators,
especially the BounceOperator, work incorrectly (because the dt in
operators and updaters are slightly different). Now a getDeltaTime()
method is maintained in ParticleSystem, and will return the unique dt
value (passing by reference) for use. This makes thing better, but
still very few unexpected behavours at present...
All dotosg and serialzier wrappers for functionalities above are provided.
...
According to some simple tests, the new shader support is slightly
efficient than ordinary glBegin()/end(). That means, I haven't got a
big improvement at present. I think the bottlenack here seems to be
the cull traversal time. Because operators go through the particle
list again and again (for example, the fountain in the shader example
requires 4 operators working all the time).
A really ideal solution here is to implement the particle operators in
shaders, too, and copy the results back to particle attributes. The
concept of GPGPU is good for implementing this. But in my opinion, the
Camera class seems to be too heavy for realizing such functionality in
a particle system. Myabe a light-weight ComputeDrawable class is
enough for receiving data as textures and outputting the results to
the FBO render buffer. What do you think then?
The floating error of emitters
(http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html)
is not solved this time. But what I think is worth testing is that we
could directly compute the node path from the emitter to the particle
system rather than multiplying the worldToLocal and LocalToWorld
matrices. I'll try this idea later.
"
2010-09-14 23:47:29 +08:00
|
|
|
/** Do something on all emitted particles.
|
2002-06-05 20:44:55 +08:00
|
|
|
This method is called by <CODE>ModularProgram</CODE> objects to perform some operations
|
Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT
type is supported at present. The attached osgparticleshader.cpp will
show how it works. It can also be placed in the examples folder. But I
just wonder how this example co-exists with another two (osgparticle
and osgparticleeffect)?
Member variables in Particle, including _alive, _current_size and
_current_alpha, are now merged into one Vec3 variable. Then we can
make use of the set...Pointer() methods to treat them as vertex
attribtues in GLSL. User interfaces are not changed.
Additional methods of ParticleSystem are introduced, including
setDefaultAttributesUsingShaders(), setSortMode() and
setVisibilityDistance(). You can see how they work in
osgparticleshader.cpp.
Additional user-defined particle type is introduced. Set the particle
type to USER and attach a drawable to the template. Be careful because
of possible huge memory consumption. It is highly suggested to use
display lists here.
The ParticleSystemUpdater can accepts ParticleSystem objects as child
drawables now. I myself think it is a little simpler in structure,
than creating a new geode for each particle system. Of course, the
latter is still compatible, and can be used to transform entire
particles in the world.
New particle operators: bounce, sink, damping, orbit and explosion.
The bounce and sink opeartors both use a concept of domains, and can
simulate a very basic collision of particles and objects.
New composite placer. It contains a set of placers and emit particles
from them randomly. The added virtual method size() of each placer
will help determine the probability of generating.
New virtual method operateParticles() for the Operator class. It
actually calls operate() for each particle, but can be overrode to use
speedup techniques like SSE, or even shaders in the future.
Partly fix a floating error of 'delta time' in emitter, program and
updaters. Previously they keep the _t0 variable seperately and compute
different copies of dt by themseleves, which makes some operators,
especially the BounceOperator, work incorrectly (because the dt in
operators and updaters are slightly different). Now a getDeltaTime()
method is maintained in ParticleSystem, and will return the unique dt
value (passing by reference) for use. This makes thing better, but
still very few unexpected behavours at present...
All dotosg and serialzier wrappers for functionalities above are provided.
...
According to some simple tests, the new shader support is slightly
efficient than ordinary glBegin()/end(). That means, I haven't got a
big improvement at present. I think the bottlenack here seems to be
the cull traversal time. Because operators go through the particle
list again and again (for example, the fountain in the shader example
requires 4 operators working all the time).
A really ideal solution here is to implement the particle operators in
shaders, too, and copy the results back to particle attributes. The
concept of GPGPU is good for implementing this. But in my opinion, the
Camera class seems to be too heavy for realizing such functionality in
a particle system. Myabe a light-weight ComputeDrawable class is
enough for receiving data as textures and outputting the results to
the FBO render buffer. What do you think then?
The floating error of emitters
(http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html)
is not solved this time. But what I think is worth testing is that we
could directly compute the node path from the emitter to the particle
system rather than multiplying the worldToLocal and LocalToWorld
matrices. I'll try this idea later.
"
2010-09-14 23:47:29 +08:00
|
|
|
on the particles. By default, it will call the <CODE>operate()</CODE> method for each particle.
|
|
|
|
You must override it in descendant classes.
|
|
|
|
*/
|
|
|
|
virtual void operateParticles(ParticleSystem* ps, double dt)
|
|
|
|
{
|
|
|
|
int n = ps->numParticles();
|
|
|
|
for (int i=0; i<n; ++i)
|
|
|
|
{
|
|
|
|
Particle* P = ps->getParticle(i);
|
|
|
|
if (P->isAlive() && isEnabled()) operate(P, dt);
|
|
|
|
}
|
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
|
|
|
/** Do something on a particle.
|
Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT
type is supported at present. The attached osgparticleshader.cpp will
show how it works. It can also be placed in the examples folder. But I
just wonder how this example co-exists with another two (osgparticle
and osgparticleeffect)?
Member variables in Particle, including _alive, _current_size and
_current_alpha, are now merged into one Vec3 variable. Then we can
make use of the set...Pointer() methods to treat them as vertex
attribtues in GLSL. User interfaces are not changed.
Additional methods of ParticleSystem are introduced, including
setDefaultAttributesUsingShaders(), setSortMode() and
setVisibilityDistance(). You can see how they work in
osgparticleshader.cpp.
Additional user-defined particle type is introduced. Set the particle
type to USER and attach a drawable to the template. Be careful because
of possible huge memory consumption. It is highly suggested to use
display lists here.
The ParticleSystemUpdater can accepts ParticleSystem objects as child
drawables now. I myself think it is a little simpler in structure,
than creating a new geode for each particle system. Of course, the
latter is still compatible, and can be used to transform entire
particles in the world.
New particle operators: bounce, sink, damping, orbit and explosion.
The bounce and sink opeartors both use a concept of domains, and can
simulate a very basic collision of particles and objects.
New composite placer. It contains a set of placers and emit particles
from them randomly. The added virtual method size() of each placer
will help determine the probability of generating.
New virtual method operateParticles() for the Operator class. It
actually calls operate() for each particle, but can be overrode to use
speedup techniques like SSE, or even shaders in the future.
Partly fix a floating error of 'delta time' in emitter, program and
updaters. Previously they keep the _t0 variable seperately and compute
different copies of dt by themseleves, which makes some operators,
especially the BounceOperator, work incorrectly (because the dt in
operators and updaters are slightly different). Now a getDeltaTime()
method is maintained in ParticleSystem, and will return the unique dt
value (passing by reference) for use. This makes thing better, but
still very few unexpected behavours at present...
All dotosg and serialzier wrappers for functionalities above are provided.
...
According to some simple tests, the new shader support is slightly
efficient than ordinary glBegin()/end(). That means, I haven't got a
big improvement at present. I think the bottlenack here seems to be
the cull traversal time. Because operators go through the particle
list again and again (for example, the fountain in the shader example
requires 4 operators working all the time).
A really ideal solution here is to implement the particle operators in
shaders, too, and copy the results back to particle attributes. The
concept of GPGPU is good for implementing this. But in my opinion, the
Camera class seems to be too heavy for realizing such functionality in
a particle system. Myabe a light-weight ComputeDrawable class is
enough for receiving data as textures and outputting the results to
the FBO render buffer. What do you think then?
The floating error of emitters
(http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html)
is not solved this time. But what I think is worth testing is that we
could directly compute the node path from the emitter to the particle
system rather than multiplying the worldToLocal and LocalToWorld
matrices. I'll try this idea later.
"
2010-09-14 23:47:29 +08:00
|
|
|
You must override it in descendant classes. Common operations
|
2002-06-05 20:44:55 +08:00
|
|
|
consist of modifying the particle's velocity vector. The <CODE>dt</CODE> parameter is
|
2012-03-22 01:36:20 +08:00
|
|
|
the time elapsed from last operation.
|
2002-06-05 20:44:55 +08:00
|
|
|
*/
|
2005-04-29 17:47:57 +08:00
|
|
|
virtual void operate(Particle* P, double dt) = 0;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Do something before processing particles via the <CODE>operate()</CODE> method.
|
|
|
|
Overriding this method could be necessary to query the calling <CODE>Program</CODE> object
|
2004-10-25 04:04:00 +08:00
|
|
|
for the current reference frame. If the reference frame is RELATIVE_RF, then your
|
2002-06-05 20:44:55 +08:00
|
|
|
class should prepare itself to do all operations in local coordinates.
|
|
|
|
*/
|
|
|
|
virtual void beginOperate(Program *) {}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Do something after all particles have been processed.
|
|
|
|
virtual void endOperate() {}
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~Operator() {}
|
|
|
|
Operator &operator=(const Operator &) { return *this; }
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
private:
|
2012-03-22 01:36:20 +08:00
|
|
|
bool _enabled;
|
2002-06-05 20:44:55 +08:00
|
|
|
};
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
// INLINE FUNCTIONS
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
inline Operator::Operator()
|
2005-04-29 17:47:57 +08:00
|
|
|
: osg::Object(), _enabled(true)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Operator::Operator(const Operator& copy, const osg::CopyOp& copyop)
|
|
|
|
: osg::Object(copy, copyop), _enabled(copy._enabled)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
|
|
|
inline bool Operator::isEnabled() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _enabled;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
inline void Operator::setEnabled(bool v)
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_enabled = v;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|