Slowly minimize the differences between the slow machine and the fast machine until the problem goes away. When it does, you have isolated the problem. Also bear in mind it could be the machine itself (hardware, drivers, etc.)
On Nov 10, 2009 12:42 PM, "Frank Sullivan" <knarf.navil...@gmail.com> wrote: Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the View section, but in the Camera section, the Slow App's numbers are way, way, way higher. I wonder if this tells me something about how to optimize the Slow App to bring it up to speed. The other major difference I noticed was in the threading model. The Quick App uses DrawThreadPerContext and the Slow App uses SingleThreaded. I tried getting the slow app to use DrawThreadPerContext by setting the environment variable, but it ignored that value and chose the SingleThreaded model for me. I can probably figure out why this happens, but I'm curious to know if you think this will affect performance much? Thanks so much to whomever has patience to read all this! Frank ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19436#19436 _______________________________________________ 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
