Re: [osg-users] Multiple Cameras and lagging proj matrix

Fri, 28 Dec 2012 15:06:09 -0800

I did come up with a reasonably confined solution for this, and I've added it to the osgWorks project, see: 
https://code.google.com/p/osgworks/source/browse/trunk/src/osgwTools/MultiCameraProjectionMatrix.cpp
and the associated header in include/osgwTools/MultiCameraProjectionMatrix.h.
MultiCameraProjectionMatrix is a cull callback that you attach to the subordinate POST_RENDER Camera in your scene graph. Behind the scenes, it works with the root Camera to compute the max far and min near plane values from both Cameras, computes a corresponding projection matrix, then sets that uniform per render thread. 

Glenn (and others), thanks for the extensive help and inspiration on this.
   -Paul


On 12/27/2012 11:43 AM, Paul Martz wrote:

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



_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to