Hi Adam, The osgViewer library is designed to handle your usage model seemlessly. What you describe is a single conceptual view, made up a series of viewports with a camera assigned to each one. The way this is implemented is to have a osgViewer::View with a single master osg::Camera that controls the overall view direction, then a series of slave osg::Camera, each with it's own osg::Viewport, each of these slave Camera can have it's own osg::GraphicsWindow (subclassed from osg::GraphicsContext) or sharing a single GraphicsWindow between them if you want them all on the same window. Each View has it's own CameraManipulator which manages it's masters Camera::ViewMatrix, but you can set the ViewMatrix yourself directly if you wish. The slave Camera all have a projection and view offset matrix that changes they view relative to their parent ViewMatrix. The osgcamera and osgwindows example illustrates.
For you usage you just need a single View, so using osgViewer::Viewer is the simplicist thing to use as it inherits directly from osgViewe::View so provides all the master Camera and slave Camera functionality that you need. The offsets of the different slave Camera then just need to be computed appropriately. The osgcamera and osgwindows examples illustrate how you can do this. Robert. On 27 December 2011 19:34, Adam Bruce <apalan...@gmail.com> wrote: > Hi all, > > I'm (very) new to OSG, though do have some prior graphics experience (which > could use brushing up, I'll admit). However, I just can't seem to determine > the best solution to this problem. > > I'm working on an application where, in one window, an aircraft HUD view is > being rendered. Originally, a single osg::Viewer with one camera was being > used, which works fine. However, I'm trying to implement what are essentially > "peripheral" views which are rendered to the same viewport as the same view, > on the left and right sides (I'm not using a single camera as these > peripheral views will be compressed horizontally and will allow the user to > set an arbitrary FOV for these views, stretching up to 180 degrees across all > three views). > > There is no issue with this part, per se - the problem arises from the fact > that there are jarring issues at the seams between viewports. Objects which > are partially drawn on each viewport have slight, though very clear, slight > issues in offset and scale, such that when they're crossing the boundary, > scale and immersion is broken. > > I've attempted two solutions to compare them. Currently, all views have the > same field of view and are drawn with equal size in the viewport. In one > method, I add two slave cameras to the viewer, which has its rotation set via > a manipulator (this was the implementation before I started the project) with > a view offset rotation of +/- main camera's horizontal field of view about > the Y-axis (gained by multiplying the vertical FOV by the aspect ratio, all > retrieved via getProjectionMatrixAsPerspective()) passed in as an argument. > From my understanding, as the main camera's view matrix is post-multiplied by > the slave's offset to get the final slave view matrix, this should be a > rotation about the local axis and give the correct result. In fact, in this > case, not only is there a slight scale/position issue, but there are odd > issues with the angle of the horizon getting slightly more off as the roll > increases (though the rotation itself seems to be about the correct axis, and > tests > with other axes are proven to be definitely incorrect). I've used both > matrix and quaternion rotations in case there are precision/accuracy > differences with no change in results. I've taken a look at > setUpViewFor3DSphericalDisplay() which seems to use a very similar method > (though I don't quite get the rotation about the Z-axis). > > In my other (naive, first) implementation, I use a composite viewer with > three identical cameras each with their own manipulator, set each to > identical rotations each frame, and calculate pitch and azimuth offsets for > the peripheral views based on the aircraft roll which is also calculated each > frame. This actually seems to work better than the single viewer solution, > but is not what I want and certainly doesn't seem to be the "correct" > solution. > > I'll add code if/when I can (need to clean it up quite a bit, as I've tried > this about twenty different ways) and will add information as often as I can. > > Thanks for any help you can give! > > -Adam > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=44488#44488 > > > > > > _______________________________________________ > 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
