help manage the scaling of particles, whether they should be relative to the
local coordiante frame of the particle system, or be in world coordinates.
include/osgParticle/ParticleSystem. I replaced
Particle(ptemplate? *ptemplate: _def_ptemp)
with
ptemplate? *ptemplate: _def_ptemp
in a couple of places. This should make particle creation and reuse go
a little faster without all that memory allocation and copying."
I spent some more time debugging and it turns out there was a bug in
the ParticleSystem::update_bounds function. When the bound is being
reset, both the min and max are being set to the same postion without
the radius being subtracted/added to it. When there is only one
particle alive in the system this causes it to be culled by small
feature culling. I've modifed the function so that when the bound is
reset, the radius is subtracted/added to the position. This fixes my
problem."
email from Marco)
"Most relevant news:
1) particle systems now have the "freezeOnCull" property set to false by
default. Since it is an optimization, and using it may cause some unwanted
behaviors if not handled properly, it makes more sense to turn it off by
default.
2) new "LINE" shape mode which uses GL_LINES to draw line segments that
point to the direction of motion.
3) particles can now have a rotation angle and angular velocity.
4) new AngularAccelOperator applies angular acceleration to particles.
5) particle processors such as emitters and programs can have a "start",
"end" and "reset" time coordinate. For example, an emitter may be instructed
to start emitting particles only after a certain time, stop after another
amount of time and then start again.
Update (2) is from Gideon May.
Updates (3) to (5) are from Douglas A. Pouk."
decoupled from osg::Drawable. The Drawable::getStats() virtual method
no longer exists.
Updated the Viewer to use the osg::Statistics incarnation and reformated stats
to clean it up.
