Thanks Robert. In the meantime, I worked around this issue by using a "ProxyCullVisitor" class and traversing the subgraph with that. It replaces the isCulled() functionality with a custom frustum used exclusively for culling, while using the normal camera for creating the StateGraphs. Works well for now.
Glenn Waldron / @glennwaldron On Mon, Jan 7, 2013 at 9:21 AM, Robert Osfield <robert.osfi...@gmail.com>wrote: > Hi Glenn, > > Just a quick reply as I'm just back from holiday season and rather > cold on techy topics. Currently the OSG's culling is based around > testing a internal nodes bounding sphere against the view frustum > polytope and the geometry leaves bounding boxes. With shaders having > the ability to move geometry around it obvious introduces a "where is > it now?" issue for any of the present bounding volume code that tries > to handle geometry with such shaders. Currently the OSG has an > osg::Drawable::setInitialBound(..) feature but this is really crappy > and has long deserved a complete overhaul in the face of widespread > usage of shaders. > > I don't believe tackling this issue by just providing some for of > culling callback/control would be sufficient as it's not only culling > traversals that need to test the whereabouts of geometry in the scene > graph. What exactly a general purpose solution might be I can't say > without putting some more time thinking about the topic. A good first > step would be to improve the bounding box controls in osg::Drawable so > it's better at managing user set bounding volumes. > > Robert. > > On 4 January 2013 15:44, Glenn Waldron <gwald...@gmail.com> wrote: > > Robert et al., > > > > The topic of culling vis-a-vis shaders has come up a few times recently. > > > > The issue is: if you transform or emit vertices in a vertex, geometry, or > > tessellation shader, the new position information is not available to > OSG's > > culling mechanism. This may result in visible geometry being culled. > > > > One approach is to artificially inflate the bounds of your geometry. Not > > very elegant. Cull callbacks won't help, since the visibility logic is in > > CullStack::isCulled() which executes before any cull callbacks. > > > > What I would like to do is use a custom frustum for culling. In my app I > > have just such a frustum, and I tried applying it the the current > > osg::CullingSet; but that CullingSet is automatically kept in sync with > the > > Camera frustum and my changes get overwritten. > > > > I think we need a general-purpose solution, since this topic is bound to > > come up again. Here are a couple ideas: > > > > 1) Allow the user to customize CullStack::isCulled() in some way, either > > with a callback, or by making the isCulled() variants virtual. > > > > 2) Allow the user to apply a custom visibility frustum to the > > osg::CullingSet. (Calling CullingSet::setFrustum works, but gets > > automatically overwritten when there are subsequent Transforms in the > scene > > graph.) > > > > I look forward to your thoughts. > > > > > > Glenn Waldron / @glennwaldron / osgEarth.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
