Re: [osg-users] [HELP] Cull time in stats?
Hi there, Sorry to interrupt, I have a similar issue with a flat scene graph and it's on my "Todo" list to remove position attitude transforms and flatten them onto the Geodes. My application is a CAD style application, with a scene graph that consists of 300,000 objects, each object is 1x PAT, 1x Geode and 1x Geometry, each Geometry is about 100 vertices (average) and multiple primitives. Each "Object" is wrapped in a class I have defined that contains the OSG nodes. The PAT's are used to position the objects, however I only actually need them when updating an objects position via picking/manipulating and also in-code manipulation. I was thinking to store the position/attitude/scale in my wrapper class and when they are updated, get the geometry vertices, inverse transform them with the old matrixtransform, and forward transform them with a new matrix transform. Does this sound like a feasible way of removing the Pats? Thank you, Andrew On Tue, Aug 11, 2009 at 1:29 AM, Jean-Sébastien Guay < jean-sebastien.g...@cm-labs.com> wrote: > Hi Jimmy, > > Regarding of having a flat scene graph. Does it matter if the whole scene >> will always be seen? Would it still improve the performance if I balance the >> scene graph more? >> > > In the case where the whole scene will always be seen (think about it > carefully, though, because I think these cases should be rare in practice) > then balancing the graph will not help, but removing groups and transforms > will. That is to say, if all your objects will always be visible, then in > order to reduce the cull time you need to reduce the number of objects to > traverse to get to the geometry. To reduce the draw time, you need to group > geometry so that data is uploaded to the card in good-sized chunks. > > So for example, if two objects will always be in the same position relative > to one another, place both in the same osg::Geometry, transforming the > vertices of the second one to be where the transform would have placed it > relative to the first. > > Say object 0 has vertex array V0 and object 1 has vertex array V1, and > suppose that object 0 is at world position T0 and object 1 is at position > T1, then you can build a vertex array V2 containing the vertices of both > objects like this: > > V2 = (V0, V1 + (T1 - T0)) > > (suppose the addition above will apply the same translation to all vertices > in V1) and then position the composite object at position T0. > > You can extend this if you have groups of many objects that will always be > in the same relative position from each other, of course. For example if a > city has buildings and all the buildings are static in world space, then > place them all in the world coordinate frame with no transforms or groups. > They can still be in different geometry objects if they have a sufficient > number of vertices (thousands). If not, then group several of them in the > same geometry object and use a texture atlas to texture them all with the > same texture file. > > Similar scene graph optimization tips have been discussed in the past on > the list. The archives should contain even more tips. I don't know if there > is a wiki page on openscenegraph.org that collects such tips, but if there > isn't we should create one... > > Hope this helps, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [HELP] Cull time in stats?
Hi, Thanks alot, J-C! Cheers, Jimmy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16064#16064 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [HELP] Cull time in stats?
Hi Jimmy, What will be a good-sized chunks? The bigger the better? You need to experiment on the video cards you will be using, but in general, as I said before in this thread, thousands per vertex array (perhaps tens of thousands). My scene are contains numbers of models which consist of multiple parts. Although each part will always be in the same position relative to each others, I can't really merge them to one osg::Geometry. Because they need to be able to change colour independently on run time. If your colors are being specified per vertex, then you can change the colors of a certain set of vertices without affecting the others. Or, you can have multiple geometry objects sharing the same vertex array but having distinct color arrays, as I see you've thought of below. It's not the same since OSG will still have to switch arrays for colors, but it will be less work than what you're doing now. Or just set the colors using textures and swap the textures when you need to change colors. It's more work for you to code it up, but if you're hitting bottlenecks then it's probably more important to you that you improve the frame rate, so getting your data into a format that OSG, OpenGL and your video card can process more easily will pay off. Now I am thinking about to create one huge static vertices array which will be used by all the geometry in the scene with correct indexing. Do you think this approach will help? or it might make the matter worse? It will differ from card to card, but generally one huge array is not the answer, it's more about grouping so there are 10 or 20 thousand vertices per array. You need to experiment with the granularity. You could easily make a test program where you would make a vertex array of some large number N of vertices, then two of N/2 each, then four of N/4 each and so on to experiment. Make the test reasonably close to your actual situation, but set it up so that granularity is parameterized (number of vertices per array, number of geometries per group, number of transforms above the groups, etc.) The osgUtil::Optimizer has visitors that can help you do some of the necessary operations automatically, or can show you working code to do it which you can then copy and modify. For example, the FLATTEN_STATIC_TRANSFORMS setting will remove static transform nodes, the MERGE_GEODES setting will put several geometry objects under a single geode instead of multiple geodes, and the MERGE_GEOMETRY setting will merge several geometry objects into a single one (merging arrays together). See "osgconv --help-env" for more settings, and the osgUtil::Optimizer header for pointers into the classes that do the work. Geez, I'm feel like I'm writing a novel here. I'll see if I can put this up on the wiki so I don't have to type all this up again in the future. :-) Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [HELP] Cull time in stats?
Hi, Thanks for clear things up for me, it does help alot. > To reduce the draw > time, you need to group geometry so that data is uploaded to the card in > good-sized chunks. What will be a good-sized chunks? The bigger the better? My scene are contains numbers of models which consist of multiple parts. Although each part will always be in the same position relative to each others, I can't really merge them to one osg::Geometry. Because they need to be able to change colour independently on run time. I just changed my code to share stateset, and it does help quit a bit. Now I am thinking about to create one huge static vertices array which will be used by all the geometry in the scene with correct indexing. Do you think this approach will help? or it might make the matter worse? Thanks again for your help! Cheers, Jimmy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16062#16062 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [HELP] Cull time in stats?
Hi Jimmy, Regarding of having a flat scene graph. Does it matter if the whole scene will always be seen? Would it still improve the performance if I balance the scene graph more? In the case where the whole scene will always be seen (think about it carefully, though, because I think these cases should be rare in practice) then balancing the graph will not help, but removing groups and transforms will. That is to say, if all your objects will always be visible, then in order to reduce the cull time you need to reduce the number of objects to traverse to get to the geometry. To reduce the draw time, you need to group geometry so that data is uploaded to the card in good-sized chunks. So for example, if two objects will always be in the same position relative to one another, place both in the same osg::Geometry, transforming the vertices of the second one to be where the transform would have placed it relative to the first. Say object 0 has vertex array V0 and object 1 has vertex array V1, and suppose that object 0 is at world position T0 and object 1 is at position T1, then you can build a vertex array V2 containing the vertices of both objects like this: V2 = (V0, V1 + (T1 - T0)) (suppose the addition above will apply the same translation to all vertices in V1) and then position the composite object at position T0. You can extend this if you have groups of many objects that will always be in the same relative position from each other, of course. For example if a city has buildings and all the buildings are static in world space, then place them all in the world coordinate frame with no transforms or groups. They can still be in different geometry objects if they have a sufficient number of vertices (thousands). If not, then group several of them in the same geometry object and use a texture atlas to texture them all with the same texture file. Similar scene graph optimization tips have been discussed in the past on the list. The archives should contain even more tips. I don't know if there is a wiki page on openscenegraph.org that collects such tips, but if there isn't we should create one... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [HELP] Cull time in stats?
Hi, Regarding of having a flat scene graph. Does it matter if the whole scene will always be seen? Would it still improve the performance if I balance the scene graph more? Thanks for the advice, I will try them. Cheers, Jimmy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16057#16057 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [HELP] Cull time in stats?
Hi Jimmy, I would like to know what is the Cull time in the osg stats (the blue bar) means. I notice it changes together with draw time when I zoom in/out of my scene. Cull time is both the time to do the actual culling, and the time it takes to traverse the scene graph and build the draw list (flat list of all drawables and state that need to be drawn in the frame). This list is then traversed in the draw stage, which is the draw bar (a better name for this is the "draw dispatch" - draw commands are sent to OpenGL). The GPU time is the actual time taken to do the drawing. I tried to disable the camera cull by setting NO_CULLING for the camera, but it didn't remove the cull time at all. It looks like the Cull time in the stats is some sort of culling which is done after the camera cull, probably is the CullVisitor. Is there a way to skip this culling process? I am trying to improve my app's performance at the moment. I know I can use DrawThreadPerContext instead of SingleThread. and also reuse my StateSet/StateAttribute to improve a bit. But both of them require major code change on my app. And most of time the whole scene should be rendered in my app anyway, so there is not much point to do culling, and if it can be disabled, I think it will increase my performance a lot. As I said above, the CullVisitor doesn't only do culling. And the culling it does is not very costly. Doing setCullingActive(false) does work, and if it doesn't give better results, it proves that culling is not your problem. The large cull time indicates that traversing the graph is taking a lot of time. This is most likely caused by having a very flat scene graph. If most of the time you add objects to the root of the graph, then this might be your problem. Making your graph more spatially distributed (i.e. groups that are close together put as children of a common group), and also perhaps merging objects that will always be seen together (i.e. removing group nodes) will probably help. You have way too many groups compared to drawables. Your draw time is also very high. As you said, sharing state and sharing arrays (vertex, normal, color, texcoord arrays) will help a lot. You seem to have about 27 vertices per drawable (77303/2815) which is very little. You should group many such drawables as one drawable, or if this is not possible, put the vertices for many drawables in a single vertex array, and make the drawables share the array, with the appropriate PrimitiveSets to draw the right part of the shared vertex array. Generally graphics cards work best when several thousand vertices are sent in a batch, so this will most probably help a lot with your draw time. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [HELP] Cull time in stats?
Hi, I would like to know what is the Cull time in the osg stats (the blue bar) means. I notice it changes together with draw time when I zoom in/out of my scene. I tried to disable the camera cull by setting NO_CULLING for the camera, but it didn't remove the cull time at all. It looks like the Cull time in the stats is some sort of culling which is done after the camera cull, probably is the CullVisitor. Is there a way to skip this culling process? I am trying to improve my app's performance at the moment. I know I can use DrawThreadPerContext instead of SingleThread. and also reuse my StateSet/StateAttribute to improve a bit. But both of them require major code change on my app. And most of time the whole scene should be rendered in my app anyway, so there is not much point to do culling, and if it can be disabled, I think it will increase my performance a lot. I also tried setCullingActive(false) to all the nodes in the scene, but it doesn't work. (it even increase the event time.) below is my stats under XP OSG 2.8.1, 2.83GHZ Duo CPU 2G Ram, ATI Radeon HD 2400XT . Cull: ~18 Draw: ~36 Stateset: 8100 Group:7320 Transform:1944 Geode:1974 Drawable:2815 Vertices:77303 Thank you! Cheers, Jimmy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16020#16020 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
