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_PARTICLE
|
|
|
|
|
#define OSGPARTICLE_PARTICLE 1
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
#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>
|
2002-06-05 20:44:55 +08:00
|
|
|
#include <osg/GL>
|
2009-10-22 00:40:45 +08:00
|
|
|
#include <osg/GLBeginEndAdapter>
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
namespace osgParticle
|
|
|
|
|
{
|
|
|
|
|
|
2005-10-13 02:42:36 +08:00
|
|
|
// forward declare so we can reference it
|
|
|
|
|
class ParticleSystem;
|
|
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** 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>
|
2012-03-22 01:36:20 +08:00
|
|
|
and <I>max</I> values so that <I>curr_value = min</I> when <I>t == 0</I>, and
|
2002-06-05 20:44:55 +08:00
|
|
|
<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;
|
2002-06-05 20:44:55 +08:00
|
|
|
public:
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-10-13 02:42:36 +08:00
|
|
|
enum
|
|
|
|
|
{
|
|
|
|
|
INVALID_INDEX = -1
|
|
|
|
|
};
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2003-09-03 04:39:41 +08:00
|
|
|
/**
|
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 {
|
2002-06-05 20:44:55 +08:00
|
|
|
POINT, // uses GL_POINTS as primitive
|
|
|
|
|
QUAD, // uses GL_QUADS as primitive
|
2005-04-29 17:47:57 +08:00
|
|
|
QUAD_TRIANGLESTRIP, // uses GL_TRI_angleSTRIP as primitive, but each particle needs a glBegin/glEnd pair
|
2003-09-03 04:39:41 +08:00
|
|
|
HEXAGON, // may save some filling time, but uses more triangles
|
2012-03-22 01:36:20 +08:00
|
|
|
LINE, // uses GL_LINES to draw line segments that point to the direction of motion
|
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
|
|
|
USER // uses a user-defined drawable as primitive
|
2002-06-05 20:44:55 +08:00
|
|
|
};
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
Particle();
|
|
|
|
|
|
|
|
|
|
/// Get the shape of the particle.
|
|
|
|
|
inline Shape getShape() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the shape of the particle.
|
|
|
|
|
inline void setShape(Shape s);
|
|
|
|
|
|
|
|
|
|
/// Get whether the particle is still alive.
|
|
|
|
|
inline bool isAlive() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the life time of the particle (in seconds).
|
|
|
|
|
inline double getLifeTime() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the age of the particle (in seconds).
|
|
|
|
|
inline double getAge() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the minimum and maximum values for polygon size.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const rangef& getSizeRange() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the minimum and maximum values for alpha.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const rangef& getAlphaRange() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the minimum and maximum values for color.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const rangev4& getColorRange() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the interpolator for computing the size of polygons.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Interpolator* getSizeInterpolator() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the interpolator for computing alpha values.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Interpolator* getAlphaInterpolator() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the interpolator for computing color values.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Interpolator* getColorInterpolator() const;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
/** Get the physical radius of the particle.
|
|
|
|
|
For built-in operators to work correctly, lengths must be expressed in meters.
|
|
|
|
|
*/
|
|
|
|
|
inline float getRadius() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** 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;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get <CODE>1 / getMass()</CODE>.
|
|
|
|
|
inline float getMassInv() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the position vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getPosition() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Get the velocity vector.
|
|
|
|
|
For built-in operators to work correctly, remember that velocity components are expressed
|
|
|
|
|
in meters per second.
|
|
|
|
|
*/
|
2012-03-22 01:36:20 +08:00
|
|
|
inline const osg::Vec3& getVelocity() const;
|
|
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Get the previous position (the position before last update).
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getPreviousPosition() const;
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/// Get the angle vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getAngle() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/// Get the rotational velocity vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getAngularVelocity() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/// Get the previous angle vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& getPreviousAngle() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-10-13 02:42:36 +08:00
|
|
|
/// Get the current color
|
|
|
|
|
inline const osg::Vec4& getCurrentColor() const { return _current_color; }
|
|
|
|
|
|
|
|
|
|
/// Get the current alpha
|
2010-09-15 17:24:45 +08:00
|
|
|
inline float getCurrentAlpha() const { return _current_alpha; }
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-10-13 02:42:36 +08:00
|
|
|
/// Get the s texture coordinate of the bottom left of the particle
|
2009-06-19 21:09:31 +08:00
|
|
|
inline float getSTexCoord() const { return _s_coord; }
|
2005-10-13 02:42:36 +08:00
|
|
|
|
|
|
|
|
/// Get the t texture coordinate of the bottom left of the particle
|
2009-06-19 21:09:31 +08:00
|
|
|
inline float getTTexCoord() const { return _t_coord; }
|
2003-09-03 04:39:41 +08:00
|
|
|
|
2006-03-17 22:05:40 +08:00
|
|
|
/// Get width of texture tile
|
|
|
|
|
inline int getTileS() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2006-03-17 22:05:40 +08:00
|
|
|
/// Get height of texture tile
|
|
|
|
|
inline int getTileT() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2006-03-17 22:05:40 +08:00
|
|
|
/// Get number of texture tiles
|
2009-11-24 23:00:11 +08:00
|
|
|
inline int getNumTiles() const { return _end_tile - _start_tile + 1; }
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Kill the particle on next update
|
2012-03-22 01:36:20 +08:00
|
|
|
NOTE: after calling this function, the <CODE>isAlive()</CODE> method will still
|
2002-06-05 20:44:55 +08:00
|
|
|
return true until the particle is updated again.
|
|
|
|
|
*/
|
|
|
|
|
inline void kill();
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the life time of the particle.
|
|
|
|
|
inline void setLifeTime(double t);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the minimum and maximum values for polygon size.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setSizeRange(const rangef& r);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the minimum and maximum values for alpha.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAlphaRange(const rangef& r);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the minimum and maximum values for color.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setColorRange(const rangev4& r);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the interpolator for computing size values.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setSizeInterpolator(Interpolator* ri);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
|
|
|
|
/// Set the interpolator for computing alpha values.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAlphaInterpolator(Interpolator* ai);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Set the interpolator for computing color values.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setColorInterpolator(Interpolator* ci);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
/** 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);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** 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);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
|
|
|
|
/// Set the position vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setPosition(const osg::Vec3& p);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/** Set the velocity vector.
|
|
|
|
|
For built-in operators to work correctly, remember that velocity components are expressed
|
|
|
|
|
in meters per second.
|
|
|
|
|
*/
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setVelocity(const osg::Vec3& v);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Add a vector to the velocity vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void addVelocity(const osg::Vec3& dv);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// Transform position and velocity vectors by a matrix.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void transformPositionVelocity(const osg::Matrix& xform);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-08-25 22:12:08 +08:00
|
|
|
/// 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-08-25 22:12:08 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/// Set the angle vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAngle(const osg::Vec3& a);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/**
|
2012-03-22 01:36:20 +08:00
|
|
|
Set the angular velocity vector.
|
2005-04-04 15:54:52 +08:00
|
|
|
Components x, y and z are angles of rotation around the respective axis (in radians).
|
|
|
|
|
*/
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void setAngularVelocity(const osg::Vec3& v);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/// Add a vector to the angular velocity vector.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void addAngularVelocity(const osg::Vec3& dv);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-04 15:54:52 +08:00
|
|
|
/// Transform angle and angularVelocity vectors by a matrix.
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void transformAngleVelocity(const osg::Matrix& xform);
|
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
|
|
|
/** Update the particle (don't call this method manually).
|
2002-06-05 20:44:55 +08:00
|
|
|
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);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
/// 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;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// 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;
|
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
|
|
|
/// Render the particle with user-defined drawable
|
|
|
|
|
void render(osg::RenderInfo& renderInfo, const osg::Vec3& xpos, const osg::Vec3& xrot) const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
/// 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;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-07-10 17:14:46 +08:00
|
|
|
/// Get the current (interpolated) polygon size. Valid only after the first call to update().
|
|
|
|
|
inline float getCurrentSize() const;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2009-11-24 23:00:11 +08:00
|
|
|
/// 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);
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2005-10-13 02:42:36 +08:00
|
|
|
/// 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; }
|
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 depth of the particle
|
|
|
|
|
inline void setDepth(double d) { _depth = d; }
|
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 depth of the particle
|
|
|
|
|
inline double getDepth() const { return _depth; }
|
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 user-defined particle drawable
|
|
|
|
|
inline void setDrawable(osg::Drawable* d) { _drawable = d; }
|
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 user-defined particle drawable
|
|
|
|
|
inline osg::Drawable* getDrawable() const { return _drawable.get(); }
|
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
|
|
|
/// Sorting operator
|
|
|
|
|
bool operator<(const Particle &P) const { return _depth < P._depth; }
|
2005-10-13 02:42:36 +08:00
|
|
|
|
|
|
|
|
/// Method for initializing a particles texture coords as part of a connected particle system.
|
|
|
|
|
void setUpTexCoordsAsPartOfConnectedParticleSystem(ParticleSystem* ps);
|
|
|
|
|
|
|
|
|
|
protected:
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
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;
|
|
|
|
|
|
2012-03-22 01:36:20 +08:00
|
|
|
double _t0;
|
2005-04-29 17:47:57 +08:00
|
|
|
|
2010-09-15 17:24:45 +08:00
|
|
|
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
|
2005-04-29 17:47:57 +08:00
|
|
|
osg::Vec4 _current_color;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
float _s_tile;
|
|
|
|
|
float _t_tile;
|
2009-11-24 23:00:11 +08:00
|
|
|
int _start_tile;
|
|
|
|
|
int _end_tile;
|
2005-04-29 17:47:57 +08:00
|
|
|
int _cur_tile;
|
|
|
|
|
float _s_coord;
|
|
|
|
|
float _t_coord;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-10-11 17:47:28 +08:00
|
|
|
// previous and next Particles are only used in ConnectedParticleSystems
|
2005-10-13 02:42:36 +08:00
|
|
|
int _previousParticle;
|
|
|
|
|
int _nextParticle;
|
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
|
|
|
// the depth of the particle is used only when sorting is enabled
|
|
|
|
|
double _depth;
|
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
|
|
|
// the particle drawable is used only when USER shape is enabled
|
|
|
|
|
osg::ref_ptr<osg::Drawable> _drawable;
|
2002-06-05 20:44:55 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// INLINE FUNCTIONS
|
|
|
|
|
|
|
|
|
|
inline Particle::Shape Particle::getShape() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _shape;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline void Particle::setShape(Shape s)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_shape = s;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline bool Particle::isAlive() const
|
|
|
|
|
{
|
2010-09-15 17:24:45 +08:00
|
|
|
return _alive>0.0f;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline double Particle::getLifeTime() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _lifeTime;
|
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 double Particle::getAge() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _t0;
|
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 float Particle::getRadius() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _radius;
|
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 Particle::setRadius(float r)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_radius = r;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const rangef& Particle::getSizeRange() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _sr;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const rangef& Particle::getAlphaRange() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _ar;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const rangev4& Particle::getColorRange() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _cr;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Interpolator* Particle::getSizeInterpolator() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _si.get();
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Interpolator* Particle::getAlphaInterpolator() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _ai.get();
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const Interpolator* Particle::getColorInterpolator() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _ci.get();
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& Particle::getPosition() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _position;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& Particle::getVelocity() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _velocity;
|
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::Vec3& Particle::getPreviousPosition() const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _prev_pos;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& Particle::getAngle() const
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _angle;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& Particle::getAngularVelocity() const
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _angul_arvel;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline const osg::Vec3& Particle::getPreviousAngle() const
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _prev_angle;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2006-03-17 22:05:40 +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;
|
|
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
inline void Particle::kill()
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_mustdie = true;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline void Particle::setLifeTime(double t)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_lifeTime = t;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setSizeRange(const rangef& r)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_sr = r;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setAlphaRange(const rangef& r)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_ar = r;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setColorRange(const rangev4& r)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_cr = r;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setSizeInterpolator(Interpolator* ri)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_si = ri;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setAlphaInterpolator(Interpolator* ai)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_ai = ai;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setColorInterpolator(Interpolator* ci)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_ci = ci;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setPosition(const osg::Vec3& p)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_position = p;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setVelocity(const osg::Vec3& v)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_velocity = v;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::addVelocity(const osg::Vec3& dv)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_velocity += dv;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::transformPositionVelocity(const osg::Matrix& xform)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_position = xform.preMult(_position);
|
2005-08-25 22:12:08 +08:00
|
|
|
_velocity = osg::Matrix::transform3x3(_velocity, xform);
|
|
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-08-25 22:12:08 +08:00
|
|
|
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;
|
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 Particle::setAngle(const osg::Vec3& a)
|
2003-09-03 04:39:41 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_angle = a;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::setAngularVelocity(const osg::Vec3& v)
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_angul_arvel = v;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::addAngularVelocity(const osg::Vec3& dv)
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_angul_arvel += dv;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
inline void Particle::transformAngleVelocity(const osg::Matrix& xform)
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
|
|
|
|
// this should be optimized!
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
osg::Vec3 a1 = _angle + _angul_arvel;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
_angle = xform.preMult(_angle);
|
2005-04-04 15:54:52 +08:00
|
|
|
a1 = xform.preMult(a1);
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2005-04-29 17:47:57 +08:00
|
|
|
_angul_arvel = a1 - _angle;
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2002-06-05 20:44:55 +08:00
|
|
|
inline float Particle::getMass() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _mass;
|
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 float Particle::getMassInv() const
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
return _massinv;
|
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 Particle::setMass(float m)
|
|
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
_mass = m;
|
|
|
|
|
_massinv = 1 / m;
|
2002-06-05 20:44:55 +08:00
|
|
|
}
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2009-10-22 00:40:45 +08:00
|
|
|
inline void Particle::beginRender(osg::GLBeginEndAdapter* gl) const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
switch (_shape)
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
|
|
|
|
case POINT:
|
2009-10-22 00:40:45 +08:00
|
|
|
gl->Begin(GL_POINTS);
|
2002-06-05 20:44:55 +08:00
|
|
|
break;
|
|
|
|
|
case QUAD:
|
2009-10-22 00:40:45 +08:00
|
|
|
gl->Begin(GL_QUADS);
|
2002-06-05 20:44:55 +08:00
|
|
|
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;
|
2002-06-05 20:44:55 +08:00
|
|
|
default: ;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-10-22 00:40:45 +08:00
|
|
|
|
|
|
|
|
inline void Particle::endRender(osg::GLBeginEndAdapter* gl) const
|
2002-06-05 20:44:55 +08:00
|
|
|
{
|
2005-04-29 17:47:57 +08:00
|
|
|
switch (_shape)
|
2009-10-22 00:40:45 +08:00
|
|
|
{
|
2002-06-05 20:44:55 +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();
|
2002-06-05 20:44:55 +08:00
|
|
|
break;
|
|
|
|
|
default: ;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-10-22 00:40:45 +08:00
|
|
|
|
2002-07-10 17:14:46 +08:00
|
|
|
inline float Particle::getCurrentSize() const
|
|
|
|
|
{
|
2010-09-15 17:24:45 +08:00
|
|
|
return _current_size;
|
2002-07-10 17:14:46 +08:00
|
|
|
}
|
2009-10-22 00:40:45 +08:00
|
|
|
|
2009-11-24 23:00:11 +08:00
|
|
|
|
|
|
|
|
inline void Particle::setTextureTile(int sTile, int tTile, int end)
|
2005-04-04 15:54:52 +08:00
|
|
|
{
|
2009-11-24 23:00:11 +08:00
|
|
|
setTextureTileRange(sTile, tTile, -1, end);
|
2005-04-04 15:54:52 +08:00
|
|
|
}
|
2002-06-05 20:44:55 +08:00
|
|
|
|
2009-11-24 23:00:11 +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;
|
2012-03-22 01:36:20 +08:00
|
|
|
|
2009-11-24 23:00:11 +08:00
|
|
|
if(startTile == -1)
|
|
|
|
|
{
|
|
|
|
|
_start_tile = 0;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
_start_tile = startTile;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(endTile == -1)
|
|
|
|
|
{
|
|
|
|
|
_end_tile = sTile * tTile;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
_end_tile = endTile;
|
|
|
|
|
}
|
|
|
|
|
}
|
2002-06-05 20:44:55 +08:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|