Re: [osg-users] State changes causing huge drop in framerate
hybr, I am not running a debug build. Just create a scene graph with 100 geometries, and attach a texture attribute to the stateset of each geometry. Now compare the framerate with the same scene graph, no stateset created, but a draw callback set up inside which you call renderInfo.getState()-applyTextureAttribute(0, texture). Making me believe the state 'diff' engine of OSG is very slow. I disable display lists and enable VBOs on each geometry otherwise drawImplementation or the draw callback is not called. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38299#38299 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] State changes causing huge drop in framerate
Hi, I have a very large scene graph where I have many geodes. Each of this geode has a stateset with a GPU program defined on it, contianing a vertex and a fragment shader. The GPU program instance is unique for my whole application - I am not recreating the program over and over again for every geode. This would be an easy, silly mistake. I have done performance tests and having a StateSet assigned to each Geode causes a MASSIVE performance drop. For a given model, containing thousands of geodes, the framerate goes from 64 to 30 fps just when you call getOrCreateStateSet on every geode, causing state to be created on each individual geode. An OpenGL trace shows that OSG is clever enough to avoid calling glUseProgram(id) / glUseProgram(0) in between every geode being rendered. Declaring the GPU program once, on the topmost graph node, and not on every geode, results in the same GL trace, with no performance degradation. This suggests OSG is very heavily using the CPU to 'diff' the state changes across geodes. Is there a way, maybe by fiddling with OVERRIDE/PROTECTED flags, to improve the way OSG handles state changes, in order to keep good performance? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38256#38256 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] State changes causing huge drop in framerate
Hi Fred, maybe have a look at this: http://www.bricoworks.com/articles/stateset/stateset.html I remember something like that state equality is only tested using pointers and not internal data. So, maybe you'll have to explicitly share state (that getOrCreate won't do). Sorry I can't actually answer from more experience. jp On 06/04/11 15:14, Fred Smith wrote: Hi, I have a very large scene graph where I have many geodes. Each of this geode has a stateset with a GPU program defined on it, contianing a vertex and a fragment shader. The GPU program instance is unique for my whole application - I am not recreating the program over and over again for every geode. This would be an easy, silly mistake. I have done performance tests and having a StateSet assigned to each Geode causes a MASSIVE performance drop. For a given model, containing thousands of geodes, the framerate goes from 64 to 30 fps just when you call getOrCreateStateSet on every geode, causing state to be created on each individual geode. An OpenGL trace shows that OSG is clever enough to avoid calling glUseProgram(id) / glUseProgram(0) in between every geode being rendered. Declaring the GPU program once, on the topmost graph node, and not on every geode, results in the same GL trace, with no performance degradation. This suggests OSG is very heavily using the CPU to 'diff' the state changes across geodes. Is there a way, maybe by fiddling with OVERRIDE/PROTECTED flags, to improve the way OSG handles state changes, in order to keep good performance? Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38256#38256 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] State changes causing huge drop in framerate
Hi JP, J.P. Delport wrote: Hi Fred, maybe have a look at this: http://www.bricoworks.com/articles/stateset/stateset.html I remember something like that state equality is only tested using pointers and not internal data. So, maybe you'll have to explicitly share state (that getOrCreate won't do). Sorry I can't actually answer from more experience. jp What about if I need to put a texture in my state? Often, each object has its own texture. Having distinct StateSet objects will be required, and I will be hit by the performance drop. What can I do in this case? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38258#38258 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] State changes causing huge drop in framerate
Hi, Fred When it comes to gl calls, state checks attributes values with state cache. You will never know for sure where time goes without profiler, so use one :) 64 to 30 fps change is in release mode with optimizations? If it is debug build difference may be almost not noticable with optimizations on... i remember case when debug build spent about 30ms on culling on scene while O2 build spent 4ms on same stuff. And with textures - i think you best bet is to share common state closer to scene root, and change only texture attributes when needed on leaf nodes. Also you can use texture atlases to get better batching, osgUtil::Optimizer can do this for you in some cases, but it can mess up some things like textures for reflections etc. Cheers, Sergey. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
