Hi Marcus, On 19 November 2014 21:32, Markus Hein <[email protected]> wrote:
> I'm still sitting here with making an osgexample app for SSBO's but > basically it is working as expected under a modified osg-3.2.1. I have > attached some screenshots, showing number of 512x512 particles computed > and rendered using SSBO and ComputeShaders (using nvidia K5000 quadro > adapter, vert sync at 60Hz). > > Robert, I wonder how to send my changeset , so we could compare it and > get SSBO support in OSG soon ? Easiest would be that I'm sending the zipped > files I have added and changed, is this ok ? > Just send a zipped file containing all the modified files, or a diff generated by svn. > Something that still makes me headache is how we could get the computation > traversal running stable in its own thread? Putting physics computation in > the mainloop could easy make it numerical instable (user events like > windowresizing, low renderrate etc.) I did some tests with running it in > two seperate threads so the computation thread was scheduled for running > straight at 120 hz and wasn't toucht, while the renderthread was scheduled > to run at 30Hz and this way all the numerical stuff was predictable, even > if renderthread was slow or stalled for a second. Does someone has some > good idea how computation traversal could be done this seperate without > changing to much osg-core code? > I am not familiar with computer shaders enough to suggest how to tackle the implementation side of trying to thread it, how does OpenGL manage this? In general if you want to do threading with the OSG then you'd create either a subclass from OpenThreads::Thread or use an osg::OperationThread and add in custom osg::Operation that do the work you want to get done. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
