Hi Rafa,
On 3 April 2013 09:48, Rafa Gaitan <rafa.gai...@gmail.com> wrote: > I'm not sure if the refactor will affect the way that stereo will be > managed, but currently also exists auto-stereoscopic displays, which means > that not only find the classical two-view stereo but many views (8 or 9 are > the most common) and even in mobile devices it's also possible to find > auto-stereoscopic displays. > > Some time ago I developed a MultiviewNode to support this kind of > displays, which basically creates a RTT camera with a grid of cameras below > using a GUIEventHandler to apply the stereo displacement. Then renders the > RTT to screen and uses a shader for rendering the specific interlave of the > display. > > I knew that this wasn't the best approach but I needed to change the > projection and view matrices to get the correct stereo result and as far as > I knew this only was possible using the SceneView callbacks but not the in > slave views, or at least it wasn't possible in an easy way :). > > I'm just commenting this because I think with the new approach will be > worth to consider this kind of displays. > There new approach should be able to encompass novel displays that require multiple camera and then a second pass to render the result. In essence it won't be any different to how stereo will be done - a master Camera on the view that controls the main view and projection matrices, then slave Camera's to render the left/right or n views with the appropriate view and projection offsets, then if required a final slave Camera that does the composition. The question for me is how best to wire up the interface for the stereo support and any other schemes. One approach is to leave it low level viewer configuration where the user or a configuration file describe exactly what slave Camera are required, this will require just what we have right now in terms of the osgViewer API and implementation, the only addition would be a fully functioning viewer configuration file. Providing easier to use helper functions in osgViewer::View in addition to the viewer configuration file is what I'd like to do so the user can use either route or a combination of these - prior art to these helper functions are the View::setUpView*() methods. BTW, if you can create the appropriate viewer slave Camera and shader combination then I'd be able to wrap this up in a helper function. Robert.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
