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_PARTICLESYSTEM
|
|
|
|
|
#define OSGPARTICLE_PARTICLESYSTEM 1
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
#include <osgParticle/Export>
|
|
|
|
|
#include <osgParticle/Particle>
|
|
|
|
|
|
|
|
|
|
#include <vector>
|
|
|
|
|
#include <stack>
|
|
|
|
|
#include <algorithm>
|
|
|
|
|
#include <string>
|
|
|
|
|
|
|
|
|
|
#include <osg/Object>
|
|
|
|
|
#include <osg/Drawable>
|
|
|
|
|
#include <osg/CopyOp>
|
|
|
|
|
#include <osg/State>
|
|
|
|
|
#include <osg/Vec3>
|
|
|
|
|
#include <osg/BoundingBox>
|
|
|
|
|
|
2009-02-10 05:38:06 +08:00
|
|
|
// 9th Febrary 2009, disabled the use of ReadWriteMutex as it looks like this
|
|
|
|
|
// is introducing threading problems due to threading problems in OpenThreads::ReadWriteMutex.
|
|
|
|
|
// #define OSGPARTICLE_USE_ReadWriteMutex
|
|
|
|
|
|
|
|
|
|
#ifdef OSGPARTICLE_USE_ReadWriteMutex
|
|
|
|
|
#include <OpenThreads/ReadWriteMutex>
|
|
|
|
|
#else
|
|
|
|
|
#include <OpenThreads/Mutex>
|
|
|
|
|
#include <OpenThreads/ScopedLock>
|
|
|
|
|
#endif
|
|
|
|
|
|
2006-12-28 00:40:34 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
namespace osgParticle
|
|
|
|
|
{
|
|
|
|
|
|
2005-05-21 05:01:57 +08:00
|
|
|
/** The heart of this class library; its purpose is to hold a set of particles and manage particle creation, update, rendering and destruction.
|
|
|
|
|
* You can add this drawable to any Geode as you usually do with other
|
|
|
|
|
* Drawable classes. Each instance of ParticleSystem is a separate set of
|
|
|
|
|
* particles; it provides the interface for creating particles and iterating
|
|
|
|
|
* through them (see the Emitter and Program classes).
|
2002-06-05 20:44:55 +08:00
|
|
|
*/
|
|
|
|
|
class OSGPARTICLE_EXPORT ParticleSystem: public osg::Drawable {
|
|
|
|
|
public:
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
enum Alignment {
|
|
|
|
|
BILLBOARD,
|
|
|
|
|
FIXED
|
|
|
|
|
};
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
ParticleSystem();
|
2005-04-29 17:47:57 +08:00
|
|
|
ParticleSystem(const ParticleSystem& copy, const osg::CopyOp& copyop = osg::CopyOp::SHALLOW_COPY);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2002-06-06 21:25:36 +08:00
|
|
|
META_Object(osgParticle, ParticleSystem);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
/// Get the alignment type of particles.
|
|
|
|
|
inline Alignment getParticleAlignment() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
/// Set the alignment type of particles.
|
|
|
|
|
inline void setParticleAlignment(Alignment a);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
/// Get the X-axis alignment vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getAlignVectorX() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
/// Set the X-axis alignment vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAlignVectorX(const osg::Vec3& v);
|
2002-07-23 00:01:00 +08:00
|
|
|
|
|
|
|
|
/// Get the Y-axis alignment vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getAlignVectorY() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
/// Set the Y-axis alignment vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAlignVectorY(const osg::Vec3& v);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
/// Set the alignment vectors.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAlignVectors(const osg::Vec3& X, const osg::Vec3& Y);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2008-03-17 20:09:05 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
enum ParticleScaleReferenceFrame
|
|
|
|
|
{
|
|
|
|
|
LOCAL_COORDINATES,
|
|
|
|
|
WORLD_COORDINATES
|
|
|
|
|
};
|
|
|
|
|
|
2008-03-17 20:11:39 +08:00
|
|
|
/** Set whether the particles should be scaled relative to world coordaintes or local coordinates.*/
|
2008-03-17 20:09:05 +08:00
|
|
|
void setParticleScaleReferenceFrame(ParticleScaleReferenceFrame rf) { _particleScaleReferenceFrame = rf; }
|
2008-03-17 20:11:39 +08:00
|
|
|
|
|
|
|
|
/** Get whether the particles should be scaled relative to world coordaintes or local coordinates.*/
|
2008-03-17 20:09:05 +08:00
|
|
|
ParticleScaleReferenceFrame getParticleScaleReferenceFrame() const { return _particleScaleReferenceFrame; }
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the default bounding box
|
2012-03-22 01:36:20 +08:00
|
|
|
inline const osg::BoundingBox& getDefaultBoundingBox() const;
|
|
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Set the default bounding box.
|
|
|
|
|
The default bounding box is used when a real bounding box cannot be computed, for example
|
|
|
|
|
because no particles has been updated yet.
|
|
|
|
|
*/
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setDefaultBoundingBox(const osg::BoundingBox& bbox);
|
2002-06-05 20:44:55 +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
|
|
|
/// Return true if we use vertex arrays for rendering particles.
|
|
|
|
|
bool getUseVertexArray() const { return _useVertexArray; }
|
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
|
|
|
/** Set to use vertex arrays for rendering particles.
|
|
|
|
|
Lots of variables will be omitted: particles' shape, alive or not, visibility distance, and so on,
|
|
|
|
|
so the rendering result is not as good as we wish (although it's fast than using glBegin/glEnd).
|
|
|
|
|
We had better use this for GLSL shaders, in which particle parameters will be kept as uniforms.
|
|
|
|
|
This method is called automatically by <CODE>setDefaultAttributesUsingShaders()</CODE>.
|
|
|
|
|
*/
|
|
|
|
|
void setUseVertexArray(bool v) { _useVertexArray = 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
|
|
|
/// Return true if shaders are required.
|
|
|
|
|
bool getUseShaders() const { return _useShaders; }
|
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
|
|
|
/** Set to use GLSL shaders for rendering particles.
|
|
|
|
|
Particles' parameters will be used as shader attribute arrays, and necessary variables, including
|
|
|
|
|
the visibility distance, texture, etc, will be used and updated as uniforms.
|
|
|
|
|
*/
|
|
|
|
|
void setUseShaders(bool v) { _useShaders = v; _dirty_uniforms = true; }
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the double pass rendering flag.
|
|
|
|
|
inline bool getDoublePassRendering() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Set the double pass rendering flag.
|
|
|
|
|
Double pass rendering avoids overdraw problems between particle systems
|
2005-05-21 05:01:57 +08:00
|
|
|
and other opaque objects. If you can render all the particle systems after
|
2002-06-05 20:44:55 +08:00
|
|
|
the opaque objects, then double pass is not necessary and can be turned off (best choice).
|
2005-05-21 05:01:57 +08:00
|
|
|
If you set the default attributes with setDefaultAttributes, then the particle
|
2002-06-05 20:44:55 +08:00
|
|
|
system will fall into a transparent bin.
|
|
|
|
|
*/
|
|
|
|
|
inline void setDoublePassRendering(bool v);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Return true if the particle system is frozen.
|
2010-01-28 01:09:05 +08:00
|
|
|
bool getFrozen() const { return _frozen; }
|
2002-06-05 20:44:55 +08:00
|
|
|
inline bool isFrozen() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Set or reset the <I>frozen</I> state.
|
|
|
|
|
When the particle system is frozen, emitters and programs won't do anything on it.
|
|
|
|
|
*/
|
|
|
|
|
inline void setFrozen(bool v);
|
|
|
|
|
|
|
|
|
|
/// Get the number of allocated particles (alive + dead).
|
|
|
|
|
inline int numParticles() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the number of dead particles.
|
|
|
|
|
inline int numDeadParticles() const;
|
2005-04-04 15:54:52 +08:00
|
|
|
|
2012-03-22 01:36:20 +08:00
|
|
|
/// Get whether all particles are dead
|
2005-04-04 15:54:52 +08:00
|
|
|
inline bool areAllParticlesDead() const { return numDeadParticles()==numParticles(); }
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get a pointer to the i-th particle.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Particle* getParticle(int i);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get a const pointer to the i-th particle.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Particle* getParticle(int i) const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Create a new particle from the specified template (or the default one if <CODE>ptemplate</CODE> is null).
|
2005-04-29 17:47:57 +08:00
|
|
|
inline virtual Particle* createParticle(const Particle* ptemplate);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Destroy the i-th particle.
|
|
|
|
|
inline virtual void destroyParticle(int i);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-10-13 02:42:36 +08:00
|
|
|
/// Reuse the i-th particle.
|
|
|
|
|
inline virtual void reuseParticle(int i) { _deadparts.push(&(_particles[i])); }
|
|
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the last frame number.
|
2010-12-23 04:11:05 +08:00
|
|
|
inline unsigned int getLastFrameNumber() const;
|
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
|
|
|
/// Get the unique delta time for emitters and updaters to use
|
|
|
|
|
inline double& getDeltaTime( double currentTime );
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
/// Get a reference to the default particle template.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Particle& getDefaultParticleTemplate();
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-03-24 01:05:21 +08:00
|
|
|
/// Get a const reference to the default particle template.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Particle& getDefaultParticleTemplate() const;
|
2005-03-24 01:05:21 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the default particle template (particle is copied).
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setDefaultParticleTemplate(const Particle& p);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get whether the particle system can freeze when culled
|
|
|
|
|
inline bool getFreezeOnCull() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set whether the particle system can freeze when culled (default is true)
|
|
|
|
|
inline void setFreezeOnCull(bool v);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** A useful method to set the most common <CODE>StateAttribute</CODE>'s in one call.
|
|
|
|
|
If <CODE>texturefile</CODE> is empty, then texturing is turned off.
|
|
|
|
|
*/
|
2005-04-29 17:47:57 +08:00
|
|
|
void setDefaultAttributes(const std::string& texturefile = "", bool emissive_particles = true, bool lighting = false, int texture_unit = 0);
|
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
|
|
|
/** A useful method to set the most common <CODE>StateAttribute</CODE> and use GLSL shaders to draw particles.
|
|
|
|
|
At present, when enabling shaders in the particle system, user-defined shapes will not be usable.
|
|
|
|
|
If <CODE>texturefile</CODE> is empty, then texturing is turned off.
|
|
|
|
|
*/
|
|
|
|
|
void setDefaultAttributesUsingShaders(const std::string& texturefile = "", bool emissive_particles = true, int texture_unit = 0);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// (<B>EXPERIMENTAL</B>) Get the level of detail.
|
|
|
|
|
inline int getLevelOfDetail() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** (<B>EXPERIMENTAL</B>) Set the level of detail. The total number of particles is divided by the detail value to
|
|
|
|
|
get the actual number of particles to be drawn. This value must be greater than zero.
|
|
|
|
|
*/
|
|
|
|
|
inline void setLevelOfDetail(int 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
|
|
|
enum SortMode
|
|
|
|
|
{
|
|
|
|
|
NO_SORT,
|
|
|
|
|
SORT_FRONT_TO_BACK,
|
|
|
|
|
SORT_BACK_TO_FRONT
|
|
|
|
|
};
|
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
|
|
|
/// Get the sort mode.
|
|
|
|
|
inline SortMode getSortMode() const;
|
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
|
|
|
/** Set the sort mode. It will force resorting the particle list by the Z direction of the view coordinates.
|
|
|
|
|
This can be used for the purpose of transparent rendering or <CODE>setVisibilityDistance()</CODE>.
|
|
|
|
|
*/
|
|
|
|
|
inline void setSortMode(SortMode mode);
|
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
|
|
|
/// Get the visibility distance.
|
|
|
|
|
inline double getVisibilityDistance() const;
|
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
|
|
|
/** Set the visibility distance which allows the particles to be rendered only when depth is inside the distance.
|
|
|
|
|
When using shaders, it can work well directly; otherwise the sort mode should also be set to pre-compute depth.
|
|
|
|
|
*/
|
|
|
|
|
inline void setVisibilityDistance(double distance);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
/// Update the particles. Don't call this directly, use a <CODE>ParticleSystemUpdater</CODE> instead.
|
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
|
|
|
virtual void update(double dt, osg::NodeVisitor& nv);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2007-03-28 19:30:38 +08:00
|
|
|
virtual void drawImplementation(osg::RenderInfo& renderInfo) const;
|
2003-08-18 17:24:17 +08:00
|
|
|
|
2005-05-12 22:03:22 +08:00
|
|
|
virtual osg::BoundingBox computeBound() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2009-02-10 05:38:06 +08:00
|
|
|
#ifdef OSGPARTICLE_USE_ReadWriteMutex
|
|
|
|
|
typedef OpenThreads::ReadWriteMutex ReadWriterMutex;
|
|
|
|
|
typedef OpenThreads::ScopedReadLock ScopedReadLock;
|
|
|
|
|
typedef OpenThreads::ScopedWriteLock ScopedWriteLock;
|
|
|
|
|
#else
|
|
|
|
|
typedef OpenThreads::Mutex ReadWriterMutex;
|
|
|
|
|
typedef OpenThreads::ScopedLock<OpenThreads::Mutex> ScopedReadLock;
|
|
|
|
|
typedef OpenThreads::ScopedLock<OpenThreads::Mutex> ScopedWriteLock;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
ReadWriterMutex* getReadWriteMutex() const { return &_readWriteMutex; }
|
2005-05-12 22:03:22 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
protected:
|
2002-07-18 22:20:01 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
virtual ~ParticleSystem();
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
ParticleSystem& operator=(const ParticleSystem&) { return *this; }
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void update_bounds(const osg::Vec3& p, float r);
|
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
|
|
|
void single_pass_render(osg::RenderInfo& renderInfo, const osg::Matrix& modelview) const;
|
|
|
|
|
void render_vertex_array(osg::RenderInfo& renderInfo) const;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
typedef std::vector<Particle> Particle_vector;
|
|
|
|
|
typedef std::stack<Particle*> Death_stack;
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
Particle_vector _particles;
|
|
|
|
|
Death_stack _deadparts;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
osg::BoundingBox _def_bbox;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
Alignment _alignment;
|
|
|
|
|
osg::Vec3 _align_X_axis;
|
|
|
|
|
osg::Vec3 _align_Y_axis;
|
2008-03-17 20:09:05 +08:00
|
|
|
ParticleScaleReferenceFrame _particleScaleReferenceFrame;
|
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
|
|
|
bool _useVertexArray;
|
|
|
|
|
bool _useShaders;
|
|
|
|
|
bool _dirty_uniforms;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
bool _doublepass;
|
|
|
|
|
bool _frozen;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
osg::Vec3 _bmin;
|
|
|
|
|
osg::Vec3 _bmax;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
bool _reset_bounds_flag;
|
|
|
|
|
bool _bounds_computed;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
Particle _def_ptemp;
|
2010-12-23 04:11:05 +08:00
|
|
|
mutable unsigned int _last_frame;
|
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
|
|
|
mutable bool _dirty_dt;
|
2005-04-29 17:47:57 +08:00
|
|
|
bool _freeze_on_cull;
|
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
|
|
|
double _t0;
|
|
|
|
|
double _dt;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
int _detail;
|
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
|
|
|
SortMode _sortMode;
|
|
|
|
|
double _visibilityDistance;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
mutable int _draw_count;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2009-02-10 05:38:06 +08:00
|
|
|
mutable ReadWriterMutex _readWriteMutex;
|
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-07-23 00:01:00 +08:00
|
|
|
inline ParticleSystem::Alignment ParticleSystem::getParticleAlignment() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _alignment;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-23 00:01:00 +08:00
|
|
|
inline void ParticleSystem::setParticleAlignment(Alignment a)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_alignment = a;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& ParticleSystem::getAlignVectorX() const
|
2002-07-23 00:01:00 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _align_X_axis;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void ParticleSystem::setAlignVectorX(const osg::Vec3& v)
|
2002-07-23 00:01:00 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_align_X_axis = v;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& ParticleSystem::getAlignVectorY() const
|
2002-07-23 00:01:00 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _align_Y_axis;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void ParticleSystem::setAlignVectorY(const osg::Vec3& v)
|
2002-07-23 00:01:00 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_align_Y_axis = v;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void ParticleSystem::setAlignVectors(const osg::Vec3& X, const osg::Vec3& Y)
|
2002-07-23 00:01:00 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_align_X_axis = X;
|
|
|
|
|
_align_Y_axis = Y;
|
2002-07-23 00:01:00 +08:00
|
|
|
}
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
inline bool ParticleSystem::isFrozen() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _frozen;
|
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 ParticleSystem::setFrozen(bool v)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_frozen = v;
|
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 const osg::BoundingBox& ParticleSystem::getDefaultBoundingBox() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _def_bbox;
|
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 void ParticleSystem::setDefaultBoundingBox(const osg::BoundingBox& bbox)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_def_bbox = bbox;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline bool ParticleSystem::getDoublePassRendering() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _doublepass;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline void ParticleSystem::setDoublePassRendering(bool v)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_doublepass = v;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline int ParticleSystem::numParticles() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return static_cast<int>(_particles.size());
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline int ParticleSystem::numDeadParticles() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return static_cast<int>(_deadparts.size());
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Particle* ParticleSystem::getParticle(int i)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return &_particles[i];
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Particle* ParticleSystem::getParticle(int i) const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return &_particles[i];
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline void ParticleSystem::destroyParticle(int i)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_particles[i].kill();
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2010-12-23 04:11:05 +08:00
|
|
|
inline unsigned int ParticleSystem::getLastFrameNumber() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _last_frame;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
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
|
|
|
inline double& ParticleSystem::getDeltaTime( double currentTime )
|
|
|
|
|
{
|
|
|
|
|
if ( _dirty_dt )
|
|
|
|
|
{
|
|
|
|
|
_dt = currentTime - _t0;
|
|
|
|
|
if ( _dt<0.0 ) _dt = 0.0;
|
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
|
|
|
_t0 = currentTime;
|
|
|
|
|
_dirty_dt = false;
|
|
|
|
|
}
|
|
|
|
|
return _dt;
|
|
|
|
|
}
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void ParticleSystem::update_bounds(const osg::Vec3& p, float r)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
if (_reset_bounds_flag) {
|
|
|
|
|
_reset_bounds_flag = false;
|
2005-11-14 17:31:06 +08:00
|
|
|
_bmin = p - osg::Vec3(r,r,r);
|
|
|
|
|
_bmax = p + osg::Vec3(r,r,r);
|
2002-06-05 20:44:55 +08:00
|
|
|
} else {
|
2005-04-29 17:47:57 +08:00
|
|
|
if (p.x() - r < _bmin.x()) _bmin.x() = p.x() - r;
|
|
|
|
|
if (p.y() - r < _bmin.y()) _bmin.y() = p.y() - r;
|
|
|
|
|
if (p.z() - r < _bmin.z()) _bmin.z() = p.z() - r;
|
|
|
|
|
if (p.x() + r > _bmax.x()) _bmax.x() = p.x() + r;
|
|
|
|
|
if (p.y() + r > _bmax.y()) _bmax.y() = p.y() + r;
|
|
|
|
|
if (p.z() + r > _bmax.z()) _bmax.z() = p.z() + r;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
if (!_bounds_computed)
|
2006-10-02 19:26:43 +08:00
|
|
|
_bounds_computed = true;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Particle& ParticleSystem::getDefaultParticleTemplate()
|
2005-03-24 01:05:21 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _def_ptemp;
|
2005-03-24 01:05:21 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Particle& ParticleSystem::getDefaultParticleTemplate() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _def_ptemp;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void ParticleSystem::setDefaultParticleTemplate(const Particle& p)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_def_ptemp = p;
|
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 bool ParticleSystem::getFreezeOnCull() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _freeze_on_cull;
|
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 ParticleSystem::setFreezeOnCull(bool v)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_freeze_on_cull = v;
|
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 int ParticleSystem::getLevelOfDetail() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _detail;
|
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 ParticleSystem::setLevelOfDetail(int v)
|
|
|
|
|
{
|
|
|
|
|
if (v < 1) v = 1;
|
2005-04-29 17:47:57 +08:00
|
|
|
_detail = v;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
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
|
|
|
inline ParticleSystem::SortMode ParticleSystem::getSortMode() const
|
|
|
|
|
{
|
|
|
|
|
return _sortMode;
|
|
|
|
|
}
|
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
|
|
|
inline void ParticleSystem::setSortMode(SortMode mode)
|
|
|
|
|
{
|
|
|
|
|
_sortMode = mode;
|
|
|
|
|
}
|
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
|
|
|
inline double ParticleSystem::getVisibilityDistance() const
|
|
|
|
|
{
|
|
|
|
|
return _visibilityDistance;
|
|
|
|
|
}
|
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
|
|
|
inline void ParticleSystem::setVisibilityDistance(double distance)
|
|
|
|
|
{
|
|
|
|
|
_visibilityDistance = distance;
|
|
|
|
|
if (_useShaders) _dirty_uniforms = true;
|
|
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
|
|
|
|
// I'm not sure this function should be inlined...
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline Particle* ParticleSystem::createParticle(const Particle* ptemplate)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
|
|
|
|
// is there any dead particle?
|
2005-04-29 17:47:57 +08:00
|
|
|
if (!_deadparts.empty()) {
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
// retrieve a pointer to the last dead particle
|
2005-04-29 17:47:57 +08:00
|
|
|
Particle* P = _deadparts.top();
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
// create a new (alive) particle in the same place
|
2007-01-13 05:44:28 +08:00
|
|
|
*P = ptemplate? *ptemplate: _def_ptemp;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
// remove the pointer from the death stack
|
2005-04-29 17:47:57 +08:00
|
|
|
_deadparts.pop();
|
2002-06-05 20:44:55 +08:00
|
|
|
return P;
|
|
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
|
|
|
|
|
// add a new particle to the vector
|
2007-01-13 05:44:28 +08:00
|
|
|
_particles.push_back(ptemplate? *ptemplate: _def_ptemp);
|
2005-04-29 17:47:57 +08:00
|
|
|
return &_particles.back();
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|