Hi Glenn -- I've managed to compute the matrix I need using the clamp projection
callbacks, so thanks for directing my attention there.
But I've ran into problems with multithreading, and it seems like you should
have the same issues, so...
1) When your cull callback sets the matrix uniform value, how are you ensuring
that's thread safe? How do you avoid thread collisions from multiple cull
threads writing the same uniform, or one draw thread reading it while another
cull thread writes it?
2) And, along the same lines, it seems like the computed near/far (and resulting
projection matrix) would be different for each render thread (depending on what
was in that thread's view frustum). What technique are you using that lets you
set a different uniform value per render thread?
Thanks.
-Paul
On 12/15/2012 2:54 PM, Glenn Waldron wrote:
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 <pma...@skew-matrix.com
<mailto:pma...@skew-matrix.com>> 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 <pma...@skew-matrix.com
<mailto:pma...@skew-matrix.com>
<mailto: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.__openscenegra__ph.org
<http://openscenegraph.org>
<mailto:osg-users@lists.__openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>>
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
<mailto:osg-users@lists.openscenegraph.org>>
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
<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
