Hi Terry,
Thanks for the explanation. Now you just need to re-read you email
and map this to osgViewer speak, you'll find it co-indices quite
nicely.
Taking it apart you say you have:
"3 views of the same scene from 3 different aircraft"
Which means... that you should have three osgViewer::View's that
represent the views from the 3 different aircraft.
Now osgViewer has two viewers, osgViewer::Viewer which "is a"
osgViewer::View so it can only do one view at time and
osgViewer::CompositeViewer which "has a" list of osgViewer::View(s).
So... which one do you want ;-)
Have a look at the osgcompositeviewer example to see it in action.
Next up you want to doing depth portitioning of your scene, with each
View having a two slave Cameras. The slave Camera support comes
virtue of the osgViewer:::View base class osg::View. Each view "has
a" master osg::Camera, and an optional list of slave osg::Camera.
Note, the slave osg::Camera aren't direct childsren of the View's
master osg::Camera, but they have their view and projection matrices
updated from the master camera.
Note II, osgViewer only threads Camera that are in the viewer, not
ones enclosed in the scene graph, so your Camera in Camera won't
thread.
Note III, the osgdepthpartion node example hasn't yet been ported to
work using slave cameras, it needs to be though, as depth portioning
is conceptually a viewer centric feature, not a scene graph centric
one. Items like shadows or reflections are scene graph centric so
are good examples for needing to use a RTT Camera in the scene graph.
Robert.
On Wed, May 28, 2008 at 4:30 PM, Terry Welsh <[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
