Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?

2009-11-10 Thread Drolet, Frederic
Hello Frank,

 

You should try to create the 52 models cache outside the rendering tree (in a 
separate list or a distinct tree detached from the camera). Even if the 
visibility is turned off, I think the rendering visitors (update, cull, etc.) 
are still browsing the whole tree. Also, don't forget that if you full your RAM 
with all the cached models, you'll have to use virtual memory on the hard drive 
which is much less efficient.

 

As for the threading model, I don't think this should affect performance much 
if you have only one display window. If you have multiple rendering context, 
it's very important to use multithreading if you wand reasonable performance. 
You can change the threading model through the 
osgViewer::Viewer::setThreadingModel() method.

 

Hope this helps!

 

Frederic Drolet, M. Sc.

Computing Solutions and Experimentations | Solutions informatiques et 
expérimentations

Systems of Systems | Systèmes de systèmes

DRDC Valcartier | RDDC Valcartier

2459, boul. Pie-XI North

Quebec, Quebec

G3J 1X5 CANADA

Phone | Téléphone: (418) 844-4000 ext : 4820

Fax | Télécopieur: (418) 844-4538

E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca

Web : www.valcartier.drdc-rddc.gc.ca http://www.valcartier.drdc-rddc.gc.ca 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Philip Lowman
Sent: November-10-09 12:52 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Would someone be willing to help me diagnose 
aperformance issue?

 

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

Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?

2009-11-10 Thread Thrall, Bryan
Frank Sullivan wrote on Tuesday, November 10, 2009 3:26 PM:
 Slow App
 -
 Lights: 0
 Bins: 30
 Depth: 0
 Matrices: 15,789
 Imposters: 0
 Drawables: 15,789
 Vertices: 1,361,039
 
 Quick App (without Object Cache)
 -
 Lights: 0
 Bins: 9
 Depth: 0
 Matrices: 1,379
 Imposters: 0
 Drawables: 1,379
 Vertices: 299,982
 
 Quick App (with Object Cache)
 -
 Lights: 0
 Bins: 9
 Depth: 0
 Matrices: 1,379
 Imposters: 0
 Drawables: 1379
 Vertices: 300,530
 
 I'm not sure exactly what these numbers mean. I thought that perhaps
they
 referred to the total number of objects in the scene graph, whether
visible
 or invisible, and whether or not they are in the viewing frustum.
However, I
 noticed that the numbers change slightly depending on where I place
the
 camera (therefore, I tried to place the camera in the same position
for each
 of the data samples above to get the most comparable results). Also,
if that
 were the case, then Quick App (with Object Cache) should have numbers
 comparable to Slow App -- they both have the exact same objects loaded
and
 attached to the scene graph. However, both versions of the Quick App
have
 similar numbers, while the Slow App numbers are way, way higher.

 
 If anyone can help explain what these stats actually refer to, I think
I may
 be able to track this problem down. 

I believe they refer to the number of Drawables, Vertices, etc. that are
actually rendered. It appears that your slow app is rendering about 4-5
times the number of objects. Perhaps it has multiple cameras or render
passes that the quick app does not? Perhaps models are getting added
multiple times at the same location? How do the numbers change when you
add a single model and how is that change different between the two
apps?

HTH,
-- 
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Would someone be willing to help me diagnose aperformance issue?

2009-11-10 Thread Thrall, Bryan
Frank Sullivan wrote on Tuesday, November 10, 2009 3:51 PM:

 Thanks, Bryan, I'll try and see if there's anything causing multiple
re-draws
 of the geometry or something. 
 
 Do you happen to know what the stats under the 'View' column refer to,
in
 this case? E.g., StateSet, Group, Transform, Geode, Drawable, etc.
These seem
 to refer more to higher-level osg concepts, except that this window,
too, has
 a Vertices state which is slightly different than the one under the
Camera
 column (in the Slow App's case, it's 231,648 Unique and 1,389,888
Instance). 

I haven't really dug into the stats stuff yet, but you can look at
osgViewer/StatsHandler.cpp in the source to get a start. Basically, it
uses osg::Stats, which has a map of strings (such as Number of unique
Primitives) to values. The values must be updated somewhere in the
code; likely, you can search for the string to figure out how exactly
they are calculated.

HTH,
-- 
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org