OpenSceneGraph/include/osgParticle/BoxPlacer

175 lines
5.0 KiB
Plaintext
Raw Normal View History

2006-07-18 23:21:48 +08:00
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
2006-01-17 23:18:44 +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
* (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.
*/
//Build by Zach Deedler
#ifndef OSGPARTICLE_BOX_PLACER
#define OSGPARTICLE_BOX_PLACER 1
#include <osgParticle/CenteredPlacer>
#include <osgParticle/Particle>
#include <osgParticle/range>
#include <osg/CopyOp>
#include <osg/Object>
#include <osg/Vec3>
#include <osg/Math>
namespace osgParticle
{
/** A box-shaped particle placer.
2006-01-17 23:18:44 +08:00
This placer sets the initial position of incoming particle by choosing a random position
within the volume of a box; this placer is defined by four parameters: a <I>center point</I>,
which is inherited directly from <CODE>osgParticle::CenteredPlacer</CODE>, and three ranges of values
for the valid <I>X</I>, <I>Y</I>, and <I>Z</I> coordinates.
2006-01-17 23:18:44 +08:00
*/
class BoxPlacer: public CenteredPlacer {
public:
inline BoxPlacer();
inline BoxPlacer(const BoxPlacer& copy, const osg::CopyOp& copyop = osg::CopyOp::SHALLOW_COPY);
/// Get the range of possible values along the X axis.
2006-01-17 23:18:44 +08:00
inline const rangef& getXRange() const;
/// Set the range of possible values along the X axis.
2006-01-17 23:18:44 +08:00
inline void setXRange(const rangef& r);
/// Set the range of possible values along the X axis.
2006-01-17 23:18:44 +08:00
inline void setXRange(float r1, float r2);
/// Get the range of possible values along the Y axis.
2006-01-17 23:18:44 +08:00
inline const rangef& getYRange() const;
/// Set the range of possible values along the Y axis.
2006-01-17 23:18:44 +08:00
inline void setYRange(const rangef& r);
/// Set the range of possible values along the Y axis.
2006-01-17 23:18:44 +08:00
inline void setYRange(float r1, float r2);
/// Get the range of possible values along the Z axis.
2006-01-17 23:18:44 +08:00
inline const rangef& getZRange() const;
/// Set the range of possible values along the Z axis.
2006-01-17 23:18:44 +08:00
inline void setZRange(const rangef& r);
/// Set the range of possible values along the Z axis.
2006-01-17 23:18:44 +08:00
inline void setZRange(float r1, float r2);
META_Object(osgParticle, BoxPlacer);
/// Place a particle. Do not call it manually.
inline void place(Particle* P) 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
/// return the volume of the box
inline float volume() const;
2006-01-17 23:18:44 +08:00
/// return the control position
inline osg::Vec3 getControlPosition() const;
protected:
virtual ~BoxPlacer() {}
BoxPlacer& operator=(const BoxPlacer&) { return *this; }
private:
rangef _x_range;
rangef _y_range;
rangef _z_range;
};
// INLINE FUNCTIONS
inline BoxPlacer::BoxPlacer()
: CenteredPlacer(), _x_range(-1, 1), _y_range(-1, 1), _z_range(-1, 1)
{
}
inline BoxPlacer::BoxPlacer(const BoxPlacer& copy, const osg::CopyOp& copyop)
: CenteredPlacer(copy, copyop),
_x_range(copy._x_range), _y_range(copy._y_range), _z_range(copy._z_range)
{
}
inline const rangef& BoxPlacer::getXRange() const
{
return _x_range;
}
inline void BoxPlacer::setXRange(const rangef& r)
{
_x_range = r;
}
inline void BoxPlacer::setXRange(float r1, float r2)
{
_x_range.minimum = r1;
_x_range.maximum = r2;
}
inline const rangef& BoxPlacer::getYRange() const
{
return _y_range;
}
inline void BoxPlacer::setYRange(const rangef& r)
{
_y_range = r;
}
inline void BoxPlacer::setYRange(float r1, float r2)
{
_y_range.minimum = r1;
_y_range.maximum = r2;
}
inline const rangef& BoxPlacer::getZRange() const
{
return _z_range;
}
inline void BoxPlacer::setZRange(const rangef& r)
{
_z_range = r;
}
inline void BoxPlacer::setZRange(float r1, float r2)
{
_z_range.minimum = r1;
_z_range.maximum = r2;
}
inline void BoxPlacer::place(Particle* P) const
{
osg::Vec3 pos(
getCenter().x() + _x_range.get_random(),
getCenter().y() + _y_range.get_random(),
getCenter().z() + _z_range.get_random());
P->setPosition(pos);
}
Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT type is supported at present. The attached osgparticleshader.cpp will show how it works. It can also be placed in the examples folder. But I just wonder how this example co-exists with another two (osgparticle and osgparticleeffect)? Member variables in Particle, including _alive, _current_size and _current_alpha, are now merged into one Vec3 variable. Then we can make use of the set...Pointer() methods to treat them as vertex attribtues in GLSL. User interfaces are not changed. Additional methods of ParticleSystem are introduced, including setDefaultAttributesUsingShaders(), setSortMode() and setVisibilityDistance(). You can see how they work in osgparticleshader.cpp. Additional user-defined particle type is introduced. Set the particle type to USER and attach a drawable to the template. Be careful because of possible huge memory consumption. It is highly suggested to use display lists here. The ParticleSystemUpdater can accepts ParticleSystem objects as child drawables now. I myself think it is a little simpler in structure, than creating a new geode for each particle system. Of course, the latter is still compatible, and can be used to transform entire particles in the world. New particle operators: bounce, sink, damping, orbit and explosion. The bounce and sink opeartors both use a concept of domains, and can simulate a very basic collision of particles and objects. New composite placer. It contains a set of placers and emit particles from them randomly. The added virtual method size() of each placer will help determine the probability of generating. New virtual method operateParticles() for the Operator class. It actually calls operate() for each particle, but can be overrode to use speedup techniques like SSE, or even shaders in the future. Partly fix a floating error of 'delta time' in emitter, program and updaters. Previously they keep the _t0 variable seperately and compute different copies of dt by themseleves, which makes some operators, especially the BounceOperator, work incorrectly (because the dt in operators and updaters are slightly different). Now a getDeltaTime() method is maintained in ParticleSystem, and will return the unique dt value (passing by reference) for use. This makes thing better, but still very few unexpected behavours at present... All dotosg and serialzier wrappers for functionalities above are provided. ... According to some simple tests, the new shader support is slightly efficient than ordinary glBegin()/end(). That means, I haven't got a big improvement at present. I think the bottlenack here seems to be the cull traversal time. Because operators go through the particle list again and again (for example, the fountain in the shader example requires 4 operators working all the time). A really ideal solution here is to implement the particle operators in shaders, too, and copy the results back to particle attributes. The concept of GPGPU is good for implementing this. But in my opinion, the Camera class seems to be too heavy for realizing such functionality in a particle system. Myabe a light-weight ComputeDrawable class is enough for receiving data as textures and outputting the results to the FBO render buffer. What do you think then? The floating error of emitters (http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html) is not solved this time. But what I think is worth testing is that we could directly compute the node path from the emitter to the particle system rather than multiplying the worldToLocal and LocalToWorld matrices. I'll try this idea later. "
2010-09-14 23:47:29 +08:00
inline float BoxPlacer::volume() 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
{
return (_x_range.maximum - _x_range.minimum) *
(_y_range.maximum - _y_range.minimum) *
(_z_range.maximum - _z_range.minimum);
}
2006-01-17 23:18:44 +08:00
inline osg::Vec3 BoxPlacer::getControlPosition() const
{
return getCenter();
}
}
#endif