Hi Wang Rui,
I've now reviewed your changes and while I'm not totally up and all
the design, motivations and implementation it looks sensible enough to
merge and let the community pick it up from here on out.
A couple of minor things that struck me as awkward:
1) The use of a Vec3 _base_prop in osgParticle for storing various
state variables
and then accessing/setting it via .x()/,y() etc. Either
separate variables or
accessing a vector through the [] accessor an enum for the entry
into it might
be more clear about it's function.
2) The method name size() makes one think of std::vector::size(), which could
be a little confusing if your reading the code quickly.
I'm not sure of what a better naming would be, but I thought I'd raise
this for discussion.
Robert.
On Fri, Aug 20, 2010 at 9:15 AM, Wang Rui <[email protected]> wrote:
> Hi Robert,
>
> I've already made some improvements to the osgParticle library. As a
> stage summary, I'd like to introduce some main work of main and
> discuss the future progress of the development:
>
> 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.
>
> By the way, is it necessary to post a copy of this thread to the osg-users? :)
>
> Cheers,
>
> Wang Rui
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
