Thanks for the reply. It actually sounds like you understand my setup
perfectly. One graphics window with 7 cameras. The top camera is the
one held by the osgViewer::Viewer. It has 3 child cameras. Each of
those has one more child camera. The scene is a child of all 6 slave
cameras. So I expect 7 cull threads and one draw thread. I also
expect getCameras() to return 7 instead of 1, but maybe I just don't
understand the correct behavior of this ViewerBase code.
The motivation behind all this is that I am displaying 3 views of the
same scene from 3 different aircraft. I use 2 cameras for each view
because I need better depth precision when rendering. One camera has
a frustum from 0.1 to 100.0, and the other has a frustum from 100.0 to
100000.0. The cameras are pieced together like this:
for 3 different sensors{
sensor.mNearCamera = new CameraNode;
sensor.mNearCamera->setReferenceFrame(Transform::ABSOLUTE_RF);
sensor.mNearCamera->setComputeNearFarMode(CameraNode::DO_NOT_COMPUTE_NEAR_FAR);
sensor.mNearCamera->setClearMask(GL_DEPTH_BUFFER_BIT);
sensor.mNearCamera->addChild(mScene.get());
sensor.mFarCamera = new CameraNode;
sensor.mFarCamera->setReferenceFrame(Transform::ABSOLUTE_RF);
sensor.mFarCamera->setComputeNearFarMode(CameraNode::DO_NOT_COMPUTE_NEAR_FAR);
sensor.mFarCamera->setClearMask(GL_DEPTH_BUFFER_BIT);
sensor.mFarCamera->addChild(mScene.get());
sensor.mNearCamera->setRenderOrder(Camera::POST_RENDER);
sensor.mFarCamera->addChild(sensor.mNearCamera.get());
mRoot->addChild(sensor.mFarCamera.get());
Thanks,
Terry
>
> Message: 10
> Date: Wed, 28 May 2008 09:03:41 +0100
> From: "Robert Osfield" <[EMAIL PROTECTED]>
> Subject: Re: [osg-users] threading trouble with slave cameras
> To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org>
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Terry,
>
> >From your email it's not clear the exact camera/graphics window set
> up. It does kinda sound like all the cameras share the same graphics
> window, is this right? If so then you'll only ever be able to have
> one DrawThread. If you have three slave Camera then in theory you
> should be able to have six CameraThread. However, from you diagram
> it seems that you have cameras nested within each other, rather than
> all the slaves being siblings, and you suggestion that getCameras()
> returns just one camera suggest that all the cameras are in the scene
> graph (or perhaps there is a bug).
>
> Since there is really too little specific information on your setup I
> can't really provide any insight or advice. You could explain your
> motivation for splitting the view up into so may cameras, the number
> of contexts you are driving, if all the cameras are collaborating on
> the same view. Also how are you adding the cameras into the setup?
> Perhaps some code would help.
>
> Robert.
>
> On Tue, May 27, 2008 at 11:17 PM, Terry Welsh <[EMAIL PROTECTED]> wrote:
>> Hi,
>> I just tried to replace SceneView with osgViewer::Viewer to take
>> advantage of threading. My scene has 3 views of the same scene with
>> cameras set up like this:
>>
>> Viewer camera
>> / | \
>> far_cam1 far_cam2 far_cam3
>> | | |
>> near_cam1 near_cam2 near_cam3
>> (POST_RENDER) (POST_RENDER) (POST_RENDER)
>> \ | /
>> scene
>>
>> The viewer camera is only used for clearing. The "near" and "far"
>> cameras are used to render different depth ranges of my scene to
>> prevent a lot of z-fighting; each pair of near/far cameras draws into
>> the same viewport.
>>
>> With no threading, I use 1 core at 100%. With
>> CullThreadPerCameraDrawThreadPerContext I use 1 core at 100% and
>> another core at about 25%. There are still 2 cores that are nearly
>> unused. The other threading modes do not appear to help.
>>
>> I tried to trace through the threading code in ViewerBase a little.
>> In "cameras" (the vector of osg::Cameras) there is only 1 camera, but
>> I expected to find 7. Is it impossible to have 7 cull threads in this
>> situation, or am I just setting something up wrong?
>> - Terry
>> _______________________________________________
>> 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
