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 >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > Regards, > Peter Wraae Marino > > www.osghelp.com - OpenSceneGraph support site > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
