Hello Robert,

Thanks for the changes to work with svn/trunk. I've been able to slot them into svn/trunk pretty easily, everything compiles and runs on my system. I don't know yet whether I see exactly what I should be expecting - a group of points that start in a cube then swirl outwards, particularly in the y axis.

Thanks, yes the example-app is just moving a lot particles around , nothing meaningful, based on some initial properties at startup , all per frame computation is done on GPU. Can easy be extended by adding some control data in (via uniforms). Everytime one of the 4 shaders sources is changed in editor, the new shader will be relinked and active, so it is possible to try something without recompiling the app.

I will work on a better example app because I see that it still has some issues. A good demonstration of SSBO's advantage over CPU-based particlesystems would be some computing intensive task like collisondetection of particles against other particles or against obstacles, bouncing between walls , maybe deformation etc.

SSBO's seems for me to be perfect to realize particlesystems where lots of particles are living for a long time and need to be updated all the time. Usually this was a heavy task for the CPU, on GPU it should go faster.

Unfortunately I have some flickering issues , I try to find out how to avoid this. I have not done any measurements if it runs faster if using multiple SSBO's (one per property for example), or if it runs best if all the data is put in one large SSBO (as in the current example). Probably it is better using multiple Shader Storage Buffer's.

regards, Markus
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to