Matthew Tippett wrote: > Comments within > > 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. I have heard others say that an update of OSG solved the problem. Perhaps there is a bug in specific recent versions of OSG, or maybe there was a library version mismatch between their fg and the installed libraries. In any event, I recommend doing a through "make clean", and if that doesn't work, upgrading OSG to SVN. > > 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. > No.
> 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. We were using slave cameras before, so there should be no difference there. It just occurred to me that the order I've assigned to the cameras may be forcing a serialization among all the channels; I'll check it out. >>> 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 Tim ------------------------------------------------------------------------- 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