Hi All, I have just tagged the OpenSceneGraph-3.1.6 development release:
*O**pen**SceneGraph-3.1.6, ** released on **13th May** 2013*, key deliverables in this dev release are: - New Keystone support in osgViewer for handling distortion correction and calibration for off axis projection. - New event handle scheme within osgViewer for handling viewer configurations that include distortion correction in a seamless way. *source package :* OpenSceneGraph-3.1.6.zip<http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.1.5.zip> *svn tag:* svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.1.6OpenSceneGraph -- To try out the keystone correction support try: osgviewer cow.osg --keystone mykeystone.osgt Then press Ctrl-g to bring up the calibration grid, then drag the corners of the grid around to creation the desired correction, then press Ctril-s to save the keystone values to the specified mykeystone.osgt file. Pressing Ctrl-g will hide the grid. And if then re-return the osgviewer with the same options above it'll come up with the distortion correction as saved. If you run in stereo then you will either one or more keystones, you'll new two if you are using horizontal or vertical split, one keystone for other stereo modes. I haven't tested all the options though as I don't have the hardware. Interleaved stereo doesn't present support keystone correction, this could be implemented but I don't think there is any point in it as interleaved stereo is just a desktop monitor solution as far as I'm aware. You can also use the OSG_KEYSTONE env var with either ON or OFF, and also the OSG_KEYSTONE_FILES with /pathto/left.osgt:/pathto/right.osgt. To get this keystone distortion correction working I had to revamp how stereo is done and how event handling is done when you start interacting with a scene that has distortion correction applied. In the case of stereo, it's now possible to configure the viewer to do stereo at the viewer level using slave Camera rather then the old SceneView based stereo scheme that we've used over the last decade. I haven't made this the default yet though as it's very new and needs lots of testing. The event handling required me to add a PointerData structure into osgGA that stores the the pointer position, the data range and the context that that data is associated with - the context can be the GraphicWindow or a Camera. Multiple PointerData objects are now created and assigned to each osgGA::GUIEventAdapter event object, and the PointerData is created by osgViewer::Viewer/CompositeViewer::eventTraversals() in such a way that the mouse events that come from the windows are associated with and then reprojected into the coordiates of the Camera's on the windows. Where a Camera is rendering a distortion correction mesh there is an automatic ray intersection with the distortion mesh to get the texture coordinates of the render to texture Camera that is used to render the original un-distorted corrected scene. The new PointerData scheme can now be queried by event handlers so you can find out the mouse coordinates in the various contexts, previous the event mouse coordinates would be reprojected automatically and this paper trail would have been lost. The new scheme can handle multiple levels of indirection as well. I have introduced a new set of View::computeIntersections(..) methods that utilize this new PointerData automatically for you, allowing you to pick and interact with scenes that have distortion correction applied without any need for you to jump through hoops. I've modified osgpick to use this new method - essentially just pass the GUIEventAdapter object rather than the mouse X,Y and it'll do everything for you - it's both easier to use, more robust and far more powerful. My hope that most users won't see any differences in the way they see events come in from the osgViewer, this extra functionality will be there for when you want to use it. There always a chance that something has gone amiss though, or that something in your application might need to be adapted if it makes a few too many assumptions about how mouse coordinates have been processed. So please test and let me know if you see any oddities. Cheers, Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
