Re: [osg-users] Geometry Drawing Performance
HI Frank, On Wed, Sep 15, 2010 at 7:12 PM, Frank Sullivan knarf.navil...@gmail.com wrote: The 700fps is just in wireframe mode with nothing else being drawn. Eventually I'll have to put it in a scene, and apply a special shader effect to it, which could reduce the frame rate. I don't know exactly what the frame rate will be, but I thought it might be fruitful (partially for curiosity's sake) to try some optimizations. Premature optimizations are something that you should avoid, you'll often be chasing completely irrelevant bottlenecks. I would strongly recommend just implementing things in the way that you find easiest to manage and using known standard fast paths and creating a well balanced scene graph, just be sensible, then do some basic performance testing it all looks good then move on. If you were getting 50hrz already then you have a problem, but at 700fps it suggests that things are doing just fine and nothing to worry about. As you implemented your shaders and introduce more data keep doing benchmark tests. I would suggest building up a family of animation paths that make the camera follow paths that are representative of application usage, then use these paths in your benchmarking so you got a consistent base on which to compare. As you progress you'll be able to monitor how your app is doing and spot when things start to go wrong, and if/when they do then you start looking into fixing the problems that arise. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
HI Frank, On Tue, Sep 14, 2010 at 8:10 PM, Frank Sullivan knarf.navil...@gmail.com wrote: In any case, I went for a naive implementation at first. Each drawable was an osg::Geometry object attached to an osg::Geode (which again, may have one or more osg::MatrixTransforms as parents). Each osg::Geometry had its own Vec3Array as a vertex array. The performance wasn't bad. It was around 700fps in wireframe mode on my machine. But I figured I could do better. I'm sorry but you lots my on this thread when you said you had 700fps, that's 10 times more than vsync, so already plenty fast enough. Is there a reason why 700fps isn't more than good enough? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Hi guys, The 700fps is just in wireframe mode with nothing else being drawn. Eventually I'll have to put it in a scene, and apply a special shader effect to it, which could reduce the frame rate. I don't know exactly what the frame rate will be, but I thought it might be fruitful (partially for curiosity's sake) to try some optimizations. rosme, thanks very much for your help. It appears that those features have been added since the 2.8.3 tag. Do you think I should update from the trunk to get the newest stuff? Or is there a better/safer procedure that I should follow? Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31649#31649 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Geometry Drawing Performance
Hello everybody, Can I trouble you with some questions about performance? My situation is basically this. I have a list of 54 drawables that I'm generating in-code. Not all of them are necessarily displayed on the screen at any given time, and in some cases, a certain drawables might be drawn more than once (accomplished by adding a second MatrixTransform parent above the associated Geode). In any case, I went for a naive implementation at first. Each drawable was an osg::Geometry object attached to an osg::Geode (which again, may have one or more osg::MatrixTransforms as parents). Each osg::Geometry had its own Vec3Array as a vertex array. The performance wasn't bad. It was around 700fps in wireframe mode on my machine. But I figured I could do better. So, I groups all of the verts for these 54 drawables into a single Vec3Array that all of the osg::Geometry objects shared. The primitive set (an osg::DrawArrays) would specify which subset of the vertex array to draw. I figured this would help because it would eliminate a lot of useless VBO bindings (or whatever else is going on under the hood). However, this actually cut the frame rate by about a third. This confused me, but in a way it made sense. My new master vertex array has well over a million verts! So maybe the memory requirements of this outweighs the savings I get from reducing VBO bindings? So anyway, I figured it might be a good idea to try to index this geometry, to cut down on the number of verts in the vertex array. Doing this, I was actually able to cut down the number of verts to just over two thousand. That's a savings of 99.84%! Of course, now I've got 54 separate primitive sets (I had to use osg::DrawElements, because it doesn't look like osg::DrawArrays supposed indexed geometry). But since these primitive sets are essentially vectors of USHORTs (rather than vectors of Vec3's), I'm still saving a significant amount of memory (about 725,00 bytes for the Vec3's and USHORTS versus about 16 million bytes for the huge Vec3Array). Yet, the frame rate remains at about 220fps, which is significantly lower than the naive method involving 54 separate Vec3Arrays totaling 1.4 million verts! I still have a ways to go. I'm thinking about seeing if I can use a triangle strip instead of GL_TRIANGLES, to save even more on memory used for verts. However, the logic for building the meshes with triangle strips will be much tougher, and will likely require smart use of degenerate triangles. I'm happy to do the work, but before I do, I just want to make sure that there isn't something that I'm missing. I tried setting the data variance of the osg::Geometry objects to Static, hoping that perhaps if I signal to OSG that I have no intention of changing those objects, it could put it in a more-efficient memory pool (perhaps). However, that didn't seem to affect the frame rate. Any advice at all would be greatly appreciated. Cheers, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31598#31598 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Hello again, There is something else that I thought of. Here is a diagram of what one of these drawables might look like: http://imgur.com/lefTl.gif Because of the way that this drawable is generated (by recursively subdividing a quad), the indices are not necessarily in an order that is cache-friendly. For instance, the triangle in green is composed of indices 8, 12, 41. This may cause OpenGL to have to jump around the VBO in a random access fashion. Could this cause the lower frame rates when compared to my naive brute force method? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31599#31599 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Another thing, Looking at the GL Trace output in glslDevil, it looks like my program is using vertex arrays. I can't tell for sure, but I think it is using vertex arrays because I don't see any calls to glBindBuffer and the pointer used in glVertexPointer looks like an actual pointer to data (035ce860) rather than an offset into a VBO. Is there any way to force OSG to use VBOs? I'm using 2.8.2. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31600#31600 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry Drawing Performance
Hi Frank, you layout doesn't really look cache friendly. Take a look at the optimizer and it's options especially INDEX_MESH, VERTEX_POSTTRANSFORM and VERTEX_PRETRANSFORM. http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/OptimizerOptions And of course make sure your Geometry drawables are using the fast path. -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31602#31602 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
