[osg-users] Need your help with zNear / zFar calculation

[Werner Modenbach]

Dear community,

today I need your help. Since many days I try finding a solution for my
problem - unfortunately without success.

Here are the facts:

I have a view for my scene and a camera manipulator.
The scene has a switch node holding the actual scene and some classes
for creation of shadow, ambient shadow etc.
Everything works pretty well so far.

For some reasons we decided rendering the actual scene into a texture
and displaying this texture in a hud.
So we create a texture and a rtt camera and added it to the above switch.
Then we removed the actual scene from the switch and added it as a child
to the rtt camera.

In order to get the scene moved according to the camera manipulator we
installed a cull callback updating the rtt cameras matrices:

if(renderCamera.valid()){

osg::Camera*cam=getMainCamera();

renderCamera->setViewMatrix(cam->getViewMatrix());

renderCamera->setProjectionMatrix(cam->getProjectionMatrix());

renderCamera->setClearColor(cam->getClearColor());

Without this callback all matrices are odd and zNear and zFar are both
at 0.0f.
Question 1: Why is it like that? The rtt camera is a child of the main
camera and should not need above settings. (?)
Question 2: In the original configuration zNear and zFar of the main
camera gets recalculated continuously.
                        In the rtt configuration zNear is always 0.0f
and zFar always 10000f. Why? The rtt camera is child of main camera and
it has the actual scene as a child.
                        So all cullings should take the actual scene in
account.
I'm really lost. When looking at the osgdeferred example I see the rtt
camera is just created, gets a viewport and gets a child of the main
camera. So easy!
What am I doing wrong and/or where can I start for a deeper research?

Many thanks for any help.

- Werner -



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180503/ddce367d/attachment.html>