On Wed, Dec 26, 2012 at 1:08 PM, Paul Martz <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**>> 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**>__>> >> 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.__open**scenegraph.org<http://openscenegraph.org> >> >> <mailto:osg-users@lists.**openscenegraph.org<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.__open**scenegraph.org<http://openscenegraph.org> >> >> <mailto:osg-users@lists.**openscenegraph.org<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<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 <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 <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 <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
