OpenSceneGraph/include/osgParticle/Particle

637 lines
19 KiB
Plaintext
Raw Normal View History

2006-07-18 23:21:48 +08:00
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* 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
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
//osgParticle - Copyright (C) 2002 Marco Jez
#ifndef OSGPARTICLE_PARTICLE
#define OSGPARTICLE_PARTICLE 1
#include <osgParticle/Export>
#include <osgParticle/Interpolator>
#include <osgParticle/range>
#include <osg/ref_ptr>
#include <osg/Vec3>
#include <osg/Vec4>
#include <osg/Matrix>
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
#include <osg/Drawable>
#include <osg/GL>
2009-10-22 00:40:45 +08:00
#include <osg/GLBeginEndAdapter>
namespace osgParticle
{
// forward declare so we can reference it
class ParticleSystem;
/** Implementation of a <B>particle</B>.
Objects of this class are particles, they have some graphical properties
and some physical properties. Particles are created by emitters and then placed
into Particle Systems, where they live and get updated at each frame.
Particles can either live forever (lifeTime < 0), or die after a specified
time (lifeTime >= 0). For each property which is defined as a range of values, a
"current" value will be evaluated at each frame by interpolating the <I>min</I>
and <I>max</I> values so that <I>curr_value = min</I> when <I>t == 0</I>, and
<I>curr_value = max</I> when <I>t == lifeTime</I>.
You may customize the interpolator objects to achieve any kind of transition.
If you want the particle to live forever, set its lifetime to any value <= 0;
in that case, no interpolation is done to compute real-time properties, and only
minimum values are used.
*/
class OSGPARTICLE_EXPORT Particle {
Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT type is supported at present. The attached osgparticleshader.cpp will show how it works. It can also be placed in the examples folder. But I just wonder how this example co-exists with another two (osgparticle and osgparticleeffect)? Member variables in Particle, including _alive, _current_size and _current_alpha, are now merged into one Vec3 variable. Then we can make use of the set...Pointer() methods to treat them as vertex attribtues in GLSL. User interfaces are not changed. Additional methods of ParticleSystem are introduced, including setDefaultAttributesUsingShaders(), setSortMode() and setVisibilityDistance(). You can see how they work in osgparticleshader.cpp. Additional user-defined particle type is introduced. Set the particle type to USER and attach a drawable to the template. Be careful because of possible huge memory consumption. It is highly suggested to use display lists here. The ParticleSystemUpdater can accepts ParticleSystem objects as child drawables now. I myself think it is a little simpler in structure, than creating a new geode for each particle system. Of course, the latter is still compatible, and can be used to transform entire particles in the world. New particle operators: bounce, sink, damping, orbit and explosion. The bounce and sink opeartors both use a concept of domains, and can simulate a very basic collision of particles and objects. New composite placer. It contains a set of placers and emit particles from them randomly. The added virtual method size() of each placer will help determine the probability of generating. New virtual method operateParticles() for the Operator class. It actually calls operate() for each particle, but can be overrode to use speedup techniques like SSE, or even shaders in the future. Partly fix a floating error of 'delta time' in emitter, program and updaters. Previously they keep the _t0 variable seperately and compute different copies of dt by themseleves, which makes some operators, especially the BounceOperator, work incorrectly (because the dt in operators and updaters are slightly different). Now a getDeltaTime() method is maintained in ParticleSystem, and will return the unique dt value (passing by reference) for use. This makes thing better, but still very few unexpected behavours at present... All dotosg and serialzier wrappers for functionalities above are provided. ... According to some simple tests, the new shader support is slightly efficient than ordinary glBegin()/end(). That means, I haven't got a big improvement at present. I think the bottlenack here seems to be the cull traversal time. Because operators go through the particle list again and again (for example, the fountain in the shader example requires 4 operators working all the time). A really ideal solution here is to implement the particle operators in shaders, too, and copy the results back to particle attributes. The concept of GPGPU is good for implementing this. But in my opinion, the Camera class seems to be too heavy for realizing such functionality in a particle system. Myabe a light-weight ComputeDrawable class is enough for receiving data as textures and outputting the results to the FBO render buffer. What do you think then? The floating error of emitters (http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html) is not solved this time. But what I think is worth testing is that we could directly compute the node path from the emitter to the particle system rather than multiplying the worldToLocal and LocalToWorld matrices. I'll try this idea later. "
2010-09-14 23:47:29 +08:00
friend class ParticleSystem;
public:
enum
{
INVALID_INDEX = -1
};
/**
2005-04-04 15:54:52 +08:00
Shape of particles.
NOTE: the LINE shape should be used in conjunction with FIXED alignment mode (see ParticleSystem).
*/
enum Shape {
POINT, // uses GL_POINTS as primitive
QUAD, // uses GL_QUADS as primitive
QUAD_TRIANGLESTRIP, // uses GL_TRI_angleSTRIP as primitive, but each particle needs a glBegin/glEnd pair
HEXAGON, // may save some filling time, but uses more triangles
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
LINE, // uses GL_LINES to draw line segments that point to the direction of motion
USER // uses a user-defined drawable as primitive
};
2002-07-23 00:01:00 +08:00
Particle();
/// Get the shape of the particle.
inline Shape getShape() const;
/// Set the shape of the particle.
inline void setShape(Shape s);
/// Get whether the particle is still alive.
inline bool isAlive() const;
/// Get the life time of the particle (in seconds).
inline double getLifeTime() const;
/// Get the age of the particle (in seconds).
inline double getAge() const;
/// Get the minimum and maximum values for polygon size.
inline const rangef& getSizeRange() const;
/// Get the minimum and maximum values for alpha.
inline const rangef& getAlphaRange() const;
/// Get the minimum and maximum values for color.
inline const rangev4& getColorRange() const;
/// Get the interpolator for computing the size of polygons.
inline const Interpolator* getSizeInterpolator() const;
/// Get the interpolator for computing alpha values.
inline const Interpolator* getAlphaInterpolator() const;
/// Get the interpolator for computing color values.
inline const Interpolator* getColorInterpolator() const;
/** Get the physical radius of the particle.
For built-in operators to work correctly, lengths must be expressed in meters.
*/
inline float getRadius() const;
/** Get the mass of the particle.
For built-in operators to work correctly, remember that the mass is expressed in kg.
*/
inline float getMass() const;
/// Get <CODE>1 / getMass()</CODE>.
inline float getMassInv() const;
/// Get the position vector.
inline const osg::Vec3& getPosition() const;
/** Get the velocity vector.
For built-in operators to work correctly, remember that velocity components are expressed
in meters per second.
*/
inline const osg::Vec3& getVelocity() const;
/// Get the previous position (the position before last update).
inline const osg::Vec3& getPreviousPosition() const;
2005-04-04 15:54:52 +08:00
/// Get the angle vector.
inline const osg::Vec3& getAngle() const;
2005-04-04 15:54:52 +08:00
/// Get the rotational velocity vector.
inline const osg::Vec3& getAngularVelocity() const;
2005-04-04 15:54:52 +08:00
/// Get the previous angle vector.
inline const osg::Vec3& getPreviousAngle() const;
/// Get the current color
inline const osg::Vec4& getCurrentColor() const { return _current_color; }
/// Get the current alpha
inline float getCurrentAlpha() const { return _current_alpha; }
/// Get the s texture coordinate of the bottom left of the particle
inline float getSTexCoord() const { return _s_coord; }
/// Get the t texture coordinate of the bottom left of the particle
inline float getTTexCoord() const { return _t_coord; }
/// Get width of texture tile
inline int getTileS() const;
/// Get height of texture tile
inline int getTileT() const;
/// Get number of texture tiles
inline int getNumTiles() const { return _end_tile - _start_tile + 1; }
/** Kill the particle on next update
NOTE: after calling this function, the <CODE>isAlive()</CODE> method will still
return true until the particle is updated again.
*/
inline void kill();
/// Set the life time of the particle.
inline void setLifeTime(double t);
/// Set the minimum and maximum values for polygon size.
inline void setSizeRange(const rangef& r);
/// Set the minimum and maximum values for alpha.
inline void setAlphaRange(const rangef& r);
/// Set the minimum and maximum values for color.
inline void setColorRange(const rangev4& r);
/// Set the interpolator for computing size values.
inline void setSizeInterpolator(Interpolator* ri);
/// Set the interpolator for computing alpha values.
inline void setAlphaInterpolator(Interpolator* ai);
/// Set the interpolator for computing color values.
inline void setColorInterpolator(Interpolator* ci);
/** Set the physical radius of the particle.
For built-in operators to work correctly, lengths must be expressed in meters.
*/
inline void setRadius(float r);
/** Set the mass of the particle.
For built-in operators to work correctly, remember that the mass is expressed in kg.
*/
inline void setMass(float m);
/// Set the position vector.
inline void setPosition(const osg::Vec3& p);
/** Set the velocity vector.
For built-in operators to work correctly, remember that velocity components are expressed
in meters per second.
*/
inline void setVelocity(const osg::Vec3& v);
/// Add a vector to the velocity vector.
inline void addVelocity(const osg::Vec3& dv);
/// Transform position and velocity vectors by a matrix.
inline void transformPositionVelocity(const osg::Matrix& xform);
/// Transform position and velocity vectors by a combination of two matrices
2005-11-16 05:47:24 +08:00
void transformPositionVelocity(const osg::Matrix& xform1, const osg::Matrix& xform2, float r);
2005-04-04 15:54:52 +08:00
/// Set the angle vector.
inline void setAngle(const osg::Vec3& a);
2005-04-04 15:54:52 +08:00
/**
Set the angular velocity vector.
Components x, y and z are angles of rotation around the respective axis (in radians).
*/
inline void setAngularVelocity(const osg::Vec3& v);
2005-04-04 15:54:52 +08:00
/// Add a vector to the angular velocity vector.
inline void addAngularVelocity(const osg::Vec3& dv);
2005-04-04 15:54:52 +08:00
/// Transform angle and angularVelocity vectors by a matrix.
inline void transformAngleVelocity(const osg::Matrix& xform);
2005-04-04 15:54:52 +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
/** Update the particle (don't call this method manually).
This method is called automatically by <CODE>ParticleSystem::update()</CODE>; it
updates the graphical properties of the particle for the current time,
checks whether the particle is still alive, and then updates its position
by computing <I>P = P + V * dt</I> (where <I>P</I> is the position and <I>V</I> is the velocity).
*/
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 update(double dt, bool onlyTimeStamp);
/// Perform some pre-rendering tasks. Called automatically by particle systems.
2009-10-22 00:40:45 +08:00
inline void beginRender(osg::GLBeginEndAdapter* gl) const;
/// Render the particle. Called automatically by particle systems.
2009-10-22 00:40:45 +08:00
void render(osg::GLBeginEndAdapter* gl, const osg::Vec3& xpos, const osg::Vec3& px, const osg::Vec3& py, float scale = 1.0f) const;
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
/// Render the particle with user-defined drawable
void render(osg::RenderInfo& renderInfo, const osg::Vec3& xpos, const osg::Vec3& xrot) const;
/// Perform some post-rendering tasks. Called automatically by particle systems.
2009-10-22 00:40:45 +08:00
inline void endRender(osg::GLBeginEndAdapter* gl) const;
/// Get the current (interpolated) polygon size. Valid only after the first call to update().
inline float getCurrentSize() const;
/// Specify how the particle texture is tiled.
/// All tiles in the given range are sequentially displayed during the lifetime
/// of the particle. When no range is given, all tiles are displayed during the lifetime.
inline void setTextureTileRange(int sTile, int tTile, int startTile, int endTile);
/// Same as above, range starts at 0 and ends at end
inline void setTextureTile(int sTile, int tTile, int end = -1);
/// Set the previous particle
inline void setPreviousParticle(int previous) { _previousParticle = previous; }
/// Get the previous particle
inline int getPreviousParticle() const { return _previousParticle; }
/// Set the next particle
inline void setNextParticle(int next) { _nextParticle = next; }
/// Get the const next particle
inline int getNextParticle() const { return _nextParticle; }
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 depth of the particle
inline void setDepth(double d) { _depth = d; }
/// Get the depth of the particle
inline double getDepth() const { return _depth; }
/// Set the user-defined particle drawable
inline void setDrawable(osg::Drawable* d) { _drawable = d; }
/// Get the user-defined particle drawable
inline osg::Drawable* getDrawable() const { return _drawable.get(); }
/// Sorting operator
bool operator<(const Particle &P) const { return _depth < P._depth; }
/// Method for initializing a particles texture coords as part of a connected particle system.
void setUpTexCoordsAsPartOfConnectedParticleSystem(ParticleSystem* ps);
protected:
Shape _shape;
rangef _sr;
rangef _ar;
rangev4 _cr;
osg::ref_ptr<Interpolator> _si;
osg::ref_ptr<Interpolator> _ai;
osg::ref_ptr<Interpolator> _ci;
bool _mustdie;
double _lifeTime;
float _radius;
float _mass;
float _massinv;
osg::Vec3 _prev_pos;
osg::Vec3 _position;
osg::Vec3 _velocity;
osg::Vec3 _prev_angle;
osg::Vec3 _angle;
osg::Vec3 _angul_arvel;
double _t0;
float _alive;
float _current_size;
float _current_alpha;
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
osg::Vec3 _base_prop; // [0] _alive [1] _current_size [2] _current_alpha
osg::Vec4 _current_color;
float _s_tile;
float _t_tile;
int _start_tile;
int _end_tile;
int _cur_tile;
float _s_coord;
float _t_coord;
// previous and next Particles are only used in ConnectedParticleSystems
int _previousParticle;
int _nextParticle;
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
// the depth of the particle is used only when sorting is enabled
double _depth;
// the particle drawable is used only when USER shape is enabled
osg::ref_ptr<osg::Drawable> _drawable;
};
// INLINE FUNCTIONS
inline Particle::Shape Particle::getShape() const
{
return _shape;
}
inline void Particle::setShape(Shape s)
{
_shape = s;
}
inline bool Particle::isAlive() const
{
return _alive>0.0f;
}
inline double Particle::getLifeTime() const
{
return _lifeTime;
}
inline double Particle::getAge() const
{
return _t0;
}
inline float Particle::getRadius() const
{
return _radius;
}
inline void Particle::setRadius(float r)
{
_radius = r;
}
inline const rangef& Particle::getSizeRange() const
{
return _sr;
}
inline const rangef& Particle::getAlphaRange() const
{
return _ar;
}
inline const rangev4& Particle::getColorRange() const
{
return _cr;
}
inline const Interpolator* Particle::getSizeInterpolator() const
{
return _si.get();
}
inline const Interpolator* Particle::getAlphaInterpolator() const
{
return _ai.get();
}
inline const Interpolator* Particle::getColorInterpolator() const
{
return _ci.get();
}
inline const osg::Vec3& Particle::getPosition() const
{
return _position;
}
inline const osg::Vec3& Particle::getVelocity() const
{
return _velocity;
}
inline const osg::Vec3& Particle::getPreviousPosition() const
{
return _prev_pos;
}
inline const osg::Vec3& Particle::getAngle() const
2005-04-04 15:54:52 +08:00
{
return _angle;
2005-04-04 15:54:52 +08:00
}
inline const osg::Vec3& Particle::getAngularVelocity() const
2005-04-04 15:54:52 +08:00
{
return _angul_arvel;
2005-04-04 15:54:52 +08:00
}
inline const osg::Vec3& Particle::getPreviousAngle() const
2005-04-04 15:54:52 +08:00
{
return _prev_angle;
2005-04-04 15:54:52 +08:00
}
inline int Particle::getTileS() const
{
return (_s_tile>0.0f) ? static_cast<int>(1.0f / _s_tile) : 1;
}
inline int Particle::getTileT() const
{
return (_t_tile>0.0f) ? static_cast<int>(1.0f / _t_tile) : 1;
}
inline void Particle::kill()
{
_mustdie = true;
}
inline void Particle::setLifeTime(double t)
{
_lifeTime = t;
}
inline void Particle::setSizeRange(const rangef& r)
{
_sr = r;
}
inline void Particle::setAlphaRange(const rangef& r)
{
_ar = r;
}
inline void Particle::setColorRange(const rangev4& r)
{
_cr = r;
}
inline void Particle::setSizeInterpolator(Interpolator* ri)
{
_si = ri;
}
inline void Particle::setAlphaInterpolator(Interpolator* ai)
{
_ai = ai;
}
inline void Particle::setColorInterpolator(Interpolator* ci)
{
_ci = ci;
}
inline void Particle::setPosition(const osg::Vec3& p)
{
_position = p;
}
inline void Particle::setVelocity(const osg::Vec3& v)
{
_velocity = v;
}
inline void Particle::addVelocity(const osg::Vec3& dv)
{
_velocity += dv;
}
inline void Particle::transformPositionVelocity(const osg::Matrix& xform)
{
_position = xform.preMult(_position);
_velocity = osg::Matrix::transform3x3(_velocity, xform);
}
inline void Particle::transformPositionVelocity(const osg::Matrix& xform1, const osg::Matrix& xform2, float r)
{
osg::Vec3 position1 = xform1.preMult(_position);
osg::Vec3 velocity1 = osg::Matrix::transform3x3(_velocity, xform1);
osg::Vec3 position2 = xform2.preMult(_position);
osg::Vec3 velocity2 = osg::Matrix::transform3x3(_velocity, xform2);
float one_minus_r = 1.0f-r;
_position = position1*r + position2*one_minus_r;
_velocity = velocity1*r + velocity2*one_minus_r;
}
inline void Particle::setAngle(const osg::Vec3& a)
{
_angle = a;
2005-04-04 15:54:52 +08:00
}
inline void Particle::setAngularVelocity(const osg::Vec3& v)
2005-04-04 15:54:52 +08:00
{
_angul_arvel = v;
2005-04-04 15:54:52 +08:00
}
inline void Particle::addAngularVelocity(const osg::Vec3& dv)
2005-04-04 15:54:52 +08:00
{
_angul_arvel += dv;
2005-04-04 15:54:52 +08:00
}
inline void Particle::transformAngleVelocity(const osg::Matrix& xform)
2005-04-04 15:54:52 +08:00
{
// this should be optimized!
osg::Vec3 a1 = _angle + _angul_arvel;
2005-04-04 15:54:52 +08:00
_angle = xform.preMult(_angle);
2005-04-04 15:54:52 +08:00
a1 = xform.preMult(a1);
_angul_arvel = a1 - _angle;
2005-04-04 15:54:52 +08:00
}
inline float Particle::getMass() const
{
return _mass;
}
inline float Particle::getMassInv() const
{
return _massinv;
}
inline void Particle::setMass(float m)
{
_mass = m;
_massinv = 1 / m;
}
2009-10-22 00:40:45 +08:00
inline void Particle::beginRender(osg::GLBeginEndAdapter* gl) const
{
switch (_shape)
{
case POINT:
2009-10-22 00:40:45 +08:00
gl->Begin(GL_POINTS);
break;
case QUAD:
2009-10-22 00:40:45 +08:00
gl->Begin(GL_QUADS);
break;
2005-04-04 15:54:52 +08:00
case LINE:
2009-10-22 00:40:45 +08:00
gl->Begin(GL_LINES);
2005-04-04 15:54:52 +08:00
break;
default: ;
}
}
2009-10-22 00:40:45 +08:00
inline void Particle::endRender(osg::GLBeginEndAdapter* gl) const
{
switch (_shape)
2009-10-22 00:40:45 +08:00
{
case POINT:
case QUAD:
2005-04-04 15:54:52 +08:00
case LINE:
2009-10-22 00:40:45 +08:00
gl->End();
break;
default: ;
}
}
2009-10-22 00:40:45 +08:00
inline float Particle::getCurrentSize() const
{
return _current_size;
}
2009-10-22 00:40:45 +08:00
inline void Particle::setTextureTile(int sTile, int tTile, int end)
2005-04-04 15:54:52 +08:00
{
setTextureTileRange(sTile, tTile, -1, end);
2005-04-04 15:54:52 +08:00
}
inline void Particle::setTextureTileRange(int sTile, int tTile, int startTile, int endTile)
{
_s_tile = (sTile>0) ? 1.0f / static_cast<float>(sTile) : 1.0f;
_t_tile = (tTile>0) ? 1.0f / static_cast<float>(tTile) : 1.0f;
if(startTile == -1)
{
_start_tile = 0;
}
else
{
_start_tile = startTile;
}
if(endTile == -1)
{
_end_tile = sTile * tTile;
}
else
{
_end_tile = endTile;
}
}
}
#endif