Hi Wang, Thank you for this work, I'll give it a try as soon as possible. Don't hesitate to post this message on osg-users.
Cheers, On Fri, Aug 20, 2010 at 10: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 > > -- Serge Lages http://www.tharsis-software.com
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
