Re: [osg-users] composite view and cameras question
Hi Peter, You usage is very much a case of two cameras that contribute to build a single view. David suggests the osgdepthpartion example, this is a good place to start, it creates two cameras in the scene graph for the purpose of partitioning the scene for better z precision. This was written before osgViewer came into being, and these days it'd actually be better to implement the same functionality but as two slave Camera's in a single View. The Camera settings for in scene graph or in viewer will be very similar, the main difference will be the conceptual element - the Camera configuration is really related to the viewer rather than something related to the scene so this particular task is most naturally suited to a Camera in the viewer. Practicalities also favour the slave Camera in the Viewer approach. In terms of Camera setup, have a look at the osgwindow example - this shears the projection matrix by doing a post translate. You are doing something kinda similar - but modifying the depth range of the projection matrix instead for each of the Camera, and the other difference would be that you'd disable the compute of near/far and enable culling of the near/far planes, and share the same graphics context between the two cameras. Robert. On Tue, Nov 4, 2008 at 7:25 PM, Peter Wraae Marino [EMAIL PROTECTED] wrote: Hi Robert, To answer the question about the two views, i'll have to explain the problem that made us to use the two views. We have a terrain and an airplane... the problem is the terrain has a lot of decals and was giving z-fighting problems. The terrain is generated by a 3rd party software so we are limited in adding anykind of bias to the decals or objects causing the z-problem. To solve this problem we decided to render the plane in one we and the terrain in another. This way the near-far plane is shorter for each view allowing us greater z precision. The z fighting problem disappeared and we are happy, but we never really did find an elegant way of syncing the two cameras. Perhaps there is a better solution to this problem, if so I would love to hear it. We talked about using slave cameras to solve the problem, don't know if this is the way but I was going to do some testing with it tommorow. You last suggestion about copying all view setting is also something we have talked about, but again before taking that direction I wanted to hear if there was an elegant way instead of the more hacked way of doing it. regards, Peter Wraae Marino On Tue, Nov 4, 2008 at 3:52 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Peter, On Tue, Nov 4, 2008 at 2:21 PM, Peter Wraae Marino [EMAIL PROTECTED] wrote: when having a composite view I have two camera, one for each view. Is there an elegant way of syncing these two cameras? so they have the same fov, position, direction, and so on... What is different between the two Views? I do wonder if a single View with two slave Cameras might not be more suitable. If you do have two different View's such as with two different scene graphs then perhaps sharing a single CameraManipulator between the two views might do the trick - I've never tried this though so odd things might happen. The other approach would be to attach a CameraManipulator to one View, then on each frame copy the first view's Camera settings to the second View. You'd need to break the viewer.frame() up into it's parts so you could do the sync just before the call to renderingTraversals(). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ 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] composite view and cameras question
Hi Users, when having a composite view I have two camera, one for each view. Is there an elegant way of syncing these two cameras? so they have the same fov, position, direction, and so on... -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] composite view and cameras question
Hi Peter, On Tue, Nov 4, 2008 at 2:21 PM, Peter Wraae Marino [EMAIL PROTECTED] wrote: when having a composite view I have two camera, one for each view. Is there an elegant way of syncing these two cameras? so they have the same fov, position, direction, and so on... What is different between the two Views? I do wonder if a single View with two slave Cameras might not be more suitable. If you do have two different View's such as with two different scene graphs then perhaps sharing a single CameraManipulator between the two views might do the trick - I've never tried this though so odd things might happen. The other approach would be to attach a CameraManipulator to one View, then on each frame copy the first view's Camera settings to the second View. You'd need to break the viewer.frame() up into it's parts so you could do the sync just before the call to renderingTraversals(). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] composite view and cameras question
Hi Robert, To answer the question about the two views, i'll have to explain the problem that made us to use the two views. We have a terrain and an airplane... the problem is the terrain has a lot of decals and was giving z-fighting problems. The terrain is generated by a 3rd party software so we are limited in adding anykind of bias to the decals or objects causing the z-problem. To solve this problem we decided to render the plane in one we and the terrain in another. This way the near-far plane is shorter for each view allowing us greater z precision. The z fighting problem disappeared and we are happy, but we never really did find an elegant way of syncing the two cameras. Perhaps there is a better solution to this problem, if so I would love to hear it. We talked about using slave cameras to solve the problem, don't know if this is the way but I was going to do some testing with it tommorow. You last suggestion about copying all view setting is also something we have talked about, but again before taking that direction I wanted to hear if there was an elegant way instead of the more hacked way of doing it. regards, Peter Wraae Marino On Tue, Nov 4, 2008 at 3:52 PM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Peter, On Tue, Nov 4, 2008 at 2:21 PM, Peter Wraae Marino [EMAIL PROTECTED] wrote: when having a composite view I have two camera, one for each view. Is there an elegant way of syncing these two cameras? so they have the same fov, position, direction, and so on... What is different between the two Views? I do wonder if a single View with two slave Cameras might not be more suitable. If you do have two different View's such as with two different scene graphs then perhaps sharing a single CameraManipulator between the two views might do the trick - I've never tried this though so odd things might happen. The other approach would be to attach a CameraManipulator to one View, then on each frame copy the first view's Camera settings to the second View. You'd need to break the viewer.frame() up into it's parts so you could do the sync just before the call to renderingTraversals(). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] composite view and cameras question
Peter, You could have a look at the osgdepthpartition example, which does something similar, although for different reasons - I think this was originally due to precision issues for very large scenes, but its use of multiple z ranges might help your problem. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
