Ah ha. And each Camera has it's own StateSet. I see.
My situation is a bit different, as I have a single subordinate Camera buried in
the scene graph, and it is on that Node that I want to set a projection matrix
Uniform that has a different value per render thread. I could, in theory, add
the Uniform much higher in the scene graph, at the top level slave Cameras used
to create each view. But, unfortunately, this project is a middleware utility
for use by OSG-based apps, so keeping my state and geometry local to a single
subgraph in desirable...
But thanks for the ideas and inspiration. Hopefully I can make this work yet.
-Paul
On 12/26/2012 2:31 PM, Glenn Waldron wrote:
On Wed, Dec 26, 2012 at 1:08 PM, Paul Martz <pma...@skew-matrix.com
<mailto:pma...@skew-matrix.com>> wrote:
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?
I use a separate set of uniforms for each thread with the "per-view data"
idiom. There is a std::map<osg::Camera*,PerViewData> that the cull traversal
code accesses each time based on the active Camera. Map access is protected by a
Mutex. The PerViewData structure contains the actual Uniforms for that Camera.
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?
See above.
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>
<mailto: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>
<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>
<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>
<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>__>
<mailto: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://openscenegra__ph.org> <http://openscenegraph.org>
<mailto:osg-users@lists.
<mailto:osg-users@lists.>__open__scenegraph.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://osg-users-____openscenegraph.org
<http://osg-users-__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://openscenegra__ph.org> <http://openscenegraph.org>
<mailto:osg-users@lists.
<mailto:osg-users@lists.>__open__scenegraph.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://osg-users-____openscenegraph.org
<http://osg-users-__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.__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
