Yes, you got it. cullOvelayGroup() is called during the cull traversal from an overloaded traverse() method in OverlayDecorator (which subclasses Group).
Glenn Waldron / @glennwaldron On Sat, Dec 15, 2012 at 1:54 PM, Paul Martz <[email protected]> wrote: > Thanks, Glenn -- I saw the callback for clamping the projection matrix > while I was sifting through the code, and your osgEarth example code is > very enlightening. > > Your function cullOverlayGroup(), is that a cull callback? Let me > regurgitate what it does, so you can correct me if I'm misunderstand: It > runs the CullVisitor on its subgraph, then uses the resulting clamped > projection matrix (which it gets from the clampProjection callback) as a > uniform in your shader code. Hm. Cool idea. > -Paul > > > > On 12/14/2012 1:27 PM, Glenn Waldron wrote: > >> Paul, >> I had a similar problem (I think). I installed a custom callback on the >> RTT >> camera (CullSettings::**setClampProjectionMatrixCallba**ck). This >> callback would >> call the original implementation first, then store the results of the >> projection >> matrix clamp so that I could use it immediately. >> >> You can see the custom callback here: >> >> https://github.com/gwaldron/**osgearth/blob/master/src/** >> osgEarth/ClampingTechnique.**cpp#L171<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L171> >> >> Each frame, I prime it with the current CullVisitor: >> >> https://github.com/gwaldron/**osgearth/blob/master/src/** >> osgEarth/ClampingTechnique.**cpp#L384<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L384> >> >> And then immediately use the result to set a uniform: >> >> https://github.com/gwaldron/**osgearth/blob/master/src/** >> osgEarth/ClampingTechnique.**cpp#L403<https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/ClampingTechnique.cpp#L403> >> >> Hope this helps. >> >> >> Glenn Waldron / @glennwaldron / osgEarth.org >> >> >> On Fri, Dec 14, 2012 at 3:12 PM, Paul Martz <[email protected] >> <mailto:[email protected]**>> wrote: >> >> I think I have a pretty good idea of the cause. >> >> The CullVisitor gathers near & far info during traversal but doesn't >> actually compute the final projection matrix until after the traversal >> completes. This means, obviously, that the projection matrix for the >> current >> frame hasn't been computed at the time the CullVisitor encounters my >> post-render Camera. Instead, the CullVisitor inserts last frame's >> projection >> matrix into the render graph, which is used for the box rendering. >> Then it >> completes traversal, computes the *correct* projection matrix, and >> uses this >> new matrix for the viewer root Camera's cylinder rendering. Thus, the >> two >> projection matrices are off just slightly, and the result is >> incorrect z >> interaction. >> >> But knowing this, I haven't been able to come up with a workaround. >> (Okay, >> well, short of editing the render graph after cull, which seems like >> I'd be >> asking for trouble.) So, still hoping for input from the community on >> how to >> make this work without visual artifacts. Thanks. >> -Paul >> >> >> On 12/14/2012 11:28 AM, Paul Martz wrote: >> >> Hi all -- I'm attempting to render with two Cameras, where one >> inherits the >> projection matrix of the other. But there appears to be some >> latency >> such that >> the subordinate Camera doesn't get the projection matrix until >> one frame >> late. >> You can reproduce the issue with the attached example and >> animation path. >> >> The example configures the viewer's root Camera to render to an >> FBO with >> color >> and depth textures attached. It renders a cylinder into these >> textures. A >> post-render Camera then splats the color texture into the window >> with a full >> screen quad. >> >> The problem occurs when a final post-render Camera draws the >> checkerboard box. >> It uses the depth texture an input to a fragment shader that >> performs a >> manual >> depth test. I have taken steps to ensure that this post-render >> Camera has >> RELATIVE_RF ref frame, and set it to disable near & far >> computation, so >> that it >> will inherit the projection matrix of the viewer root Camera. >> This works >> quite >> well except for the slight lag, indicating that this post-render >> Camera >> doesn't >> get the correct projection matrix until about a frame too late. >> >> The problem is definitely related to the fact that the viewer >> root Camera is >> configured to auto-compute near & far, because if I disable this >> and set >> a fixed >> projection matrix on the root Camera, the problem goes away >> (uncomment >> lines 49 >> and 50). >> >> Can anyone explain the one-frame lag with the projection matrix? >> I'll be >> digging >> into the code over the weekend to figure this out myself, but >> would >> appreciate >> any input while I dig... >> >> Thanks, >> -Paul >> >> >> >> >> >> ______________________________**___________________ >> osg-users mailing list >> osg-users@lists.__openscenegra**ph.org<http://openscenegraph.org> >> >> <mailto:osg-users@lists.**openscenegraph.org<[email protected]> >> > >> http://lists.openscenegraph.__**org/listinfo.cgi/osg-users-__** >> openscenegraph.org <http://osg-users-__openscenegraph.org> >> <http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** >> openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> > >> >> ______________________________**___________________ >> osg-users mailing list >> osg-users@lists.__openscenegra**ph.org >> <http://openscenegraph.org><mailto: >> osg-users@lists.**openscenegraph.org <[email protected]> >> > >> http://lists.openscenegraph.__**org/listinfo.cgi/osg-users-__** >> openscenegraph.org <http://osg-users-__openscenegraph.org> < >> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** >> openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> > >> >> >> >> >> >> ______________________________**_________________ >> osg-users mailing list >> osg-users@lists.**openscenegraph.org <[email protected]> >> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** >> openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> >> ______________________________**_________________ > osg-users mailing list > osg-users@lists.**openscenegraph.org <[email protected]> > http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** > openscenegraph.org<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
