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::setClampProjectionMatrixCallback). 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
Each frame, I prime it with the current CullVisitor:
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
Hope this helps.
Glenn Waldron / @glennwaldron / osgEarth.org
On Fri, Dec 14, 2012 at 3:12 PM, Paul Martz <pma...@skew-matrix.com
<mailto:pma...@skew-matrix.com>> 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.__openscenegraph.org
<mailto:osg-users@lists.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
<mailto:osg-users@lists.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
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
