Hi Robert, Thanks for the thorough response.
I am using OSG 2.2, though I'm still using the depreciated names for some of the OSG classes, sorry. I really should grep the code (and my brain) to sort that one out. My use of 2.2 comes with caveat that I can't use the new Viewer classes and am manually managing the windowing code, OpenGL context and SceneView(s). The project I'm working on was originally created to work with osg < 0.95 and there are certain legacy requirements as a result. It would be a lot of work to rip all that code out of the project and tack the osg Viewer stuff on, especially since project's structure was originally designed and tailored with the old SceneView semantics in mind. That said I might get around to it some time when there's less work to be done elsewhere! OSG evolves at such a pace it's hard for a one man project to keep up! The cull callback idea you suggest sounds like the right approach. If I grab the matrix in this way is it safe to update the value of a uniform attached to a "higher camera" from within the cull phase? I know you're not really supposed to touch the graph between updates, culls and draws, but perhaps such a small change is ok? If it's legal to do so, then I think this should solve my problem quite elegantly. I knew the correct matrix was floating around the scenegraph at some stage during the cull and draw phases, just finding it was the problem! Slightly off topic are there any plans for phasing the SceneView class out in the near/distant future? If it was suddenly removed from the OSG I'd be left with a lot of work to do. Is it safe to assume it's going to be around for a while longer or should I try and get away from it now while I'm still compatible with the current version of OSG? Thanks a lot, Alan On 4 Dec 2007, at 09:29, Robert Osfield wrote: > Hi Alan, > > Are you stuck using 1.2 or can you upgrade to 2.2? The support for > RTT in 2.2 is more flexible, using osg::Camera (renamed and improved > version of CameraNode). 2.2 allows you to place RTT cameras in the > scene graph (like what you are probably doing) as well as place them > in the viewer. When you attach an RTT camera to a viewer it is > assigned a Renderer, and the Render "has a" SceneView, so if you do > need to grapple with low level details you can do it. > > The Camera also has its own projection matrix and if you switch off > the the near/far compute it'll be valid for the all OpenGL ops. > Alternatively you could use a cull callbcack that catches the > CullVisitor after it has passed through setting up the Camera, and > then cast the NodeVisitor to CullVisitor and get its current > projection matrix from it. > > As a general note on versioning, 1.2 was made a year and half ago, so > for myself remembering all the ins and outs of what functionality was > supported/what wasn't/what gotchas or workarounds to use is very hard, > next to impossible without downloading 1.2 and reviewing it all in > attempt at providing accurate support. I'm afriad simply don't have > available time for this. > > Porting from 1.2 is 2.2 shouldn't be that hard, most of the OSG > classes are still in place, the viewer library is the biggest change, > but to ease transition you can still use osgProducer via the separate > repository for it. If you just use SceneView for your viewer then > it'd be even easier as SceneView is still there. > > Robert. > > On Dec 3, 2007 10:51 PM, Alan Purvis <[EMAIL PROTECTED]> wrote: >> Hi, >> >> CameraNodes unlike SceneViews don't appear to have a getCullVisitor() >> function, I'm guessing they're visited by the same CullVisitor as the >> root SceneView that contains them. Without access to this "root >> SceneView", is it possible to get access to the exact projection >> matrix applied to the contents of a CameraNode with an absolute frame >> of reference (and no projection transforms attached to its children >> other than the one set on itself)? >> >> I have a (heavily) multi-pass scene graph set up doing per fragment >> depth of field with some RTT pre-render passes and rendering textured >> quads to various destinations with shaders attached. One requirement >> of the algorithm I'm working on is access to the projection matrix >> used to render the original "scene texture" by the quad that is used >> to render that scene texture to the frame buffer (or another FBO >> depending), this is required to reverse the non-linear transform >> applied to values in the depth buffer among other things. Simply >> calling getProjectionMatrix() on the CameraNode after it has rendered >> its image returns the original matrix I passed it though, is the >> actual matrix used for rendering retained after culling and drawing >> have completed? If so, then where might I find it? and if not is >> there some callback or something I can use to grab it while it's >> floating around the scenegraph? >> >> Thanks, >> Alan >> _______________________________________________ >> 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 > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
