Comments within
-------- Original Message --------
Subject: Re: [Flightgear-devel] Total Cameras in statistics view
From: Tim Moore <[EMAIL PROTECTED]>
To: FlightGear developers discussions
<flightgear-devel@lists.sourceforge.net>
Date: 26/11/08 09:57 AM
Matthew Tippett wrote:
Yes. In order to draw our huge Z range -- from the tip of your nose
(more or
less) out to the horizon -- without flickering and other artifacts, the scene is
drawn twice. It's drawn with the near plane set to 100 meters, then the depth
buffer is cleared, and the scene is drawn again with the far plane at 100 meters
and the near plane at its nominal value, currently .1 meters by default. It's
been done this way for some time by a ViewPartitionNode in the scene graph. I
recently changed the scheme to use two slave cameras as the camera-like nature
of the ViewPartitionNode was screwing up view-dependent shadow work I am doing.
Plus, this is the recommended way to do such a partition, according to the
wisdom of the OSG users list. There shouldn't be any performance difference in
the change to slave cameras, but the statistics for the two cameras will be
displayed in the stats display.
Okay. So that points a smoking gun at the near camera (call it what you
will :) is not getting drawn. Is the complete code submitted? It seems
to be spending time in the draw for both the near and far camera. I
think others have seen this too.
Is there any different camera settings that are needed (I am using
camera groups as described in the README.multiscreen with defaults
except for the view.
I also notice that each camera seems to be 'paired' with another
camera - as in the 2nd camera will not start it's cull and draw until
after the previous one.
This is in a 5 camera config across 5 displays.
Because of the depth ordering, the far camera must be drawn before the near
camera. Note that this is not new behavior, it is just now exposed in the timing
statistics. I don't know why the two cull passes are serialized, unless you're
simply running out of processors to run the cull passes.
The ordering does make sense, however it appears as the secondary cull
occurs immediate after the primary draw completes. I can't get
CullThreadPerCameraDrawThreadPerContext to start up reliably, so it
might be related to that.
Does the slave cameras honor the OSG_SERIALIZE_DRAW variable (also note
that Csaba got me to remove a couple of gc.realize() calls to
deserialize the CullDrawThreadPerContext draw.
I am using the 'CullThreadPerCamera' model, with the gc.realize
commented out with the OSG_SERIALIZE_DRAW variable turned off.
I don't think that's one of the choices :) Do you mean
"CullThreadPerCameraDrawThreadPerContext"? You might try
CullDrawThreadPerContext and see if that gives better performance.
As mentioned before, there seems to be deadlocks starting up with
CullThreadPerCameraDrawThreadPerContext, but I have found that
CullDrawThreadPerContext is quite reliable now.
Regards,
Matthew
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
