Hi Paul, Adding a Drawable::g/setCullingActive(bool) to be consistent with osg::Node seems appropriate.
I also wound like to clean up the initial bound setting in Drawable to improve the situtation of where we transform the points in a geometry in the vertex shader to somewhere completely different than the initial vertex array would suggest the object is. We current have the Drawable::setInitialBound() but I'm not happy with this as it still has the vertex position contributing to the final bounding volume. As for toggling on/off the compute of the the near/far, I guess we could add a bool into Drawable for this, but I'd rather not add more bool checks than absolutely necessary. Given we can use a cull callback to cache and restore and for disabling the near/far compute locally for subgraphs that we don't want to propagate the near/far compute the actual need isn't critical. The cull callback would actually be more flexible as well, as you could disable the near/far compute for a whole subgraph. Robert. On Tue, Jan 5, 2010 at 11:35 PM, Paul Martz <[email protected]> wrote: > Hi Robert and all -- I've ran into an interesting culling issue and wanted > to raise it on the list in case someone thought there should be a code > change. > > The issue is at CullVisitor.cpp line 746. This line of code causes a > Drawable to be culled if compute near/far is on, and the call to > updateCalculatedNearFar() returns false (because the Drawable bounds place > it behind the viewpoint). > > I'm rendering a skydome with custom transformations in the vertex shader, so > the host bounding box is really quite meaningless. I want to disable culling > on the Drawable. > > There seems to be two ways to handle this: > * Set a profoundly large initial bound. (This has the unfortunate side > effect of slaughtering the near/far computation.) > * Disable near/far computation just for this subgraph. I'm currently doing > this with a custom Group node. In the traverse() method during cull. I > disable compute near/far, traverse the subgraph, then restore the saved > compute near/far mode. (Is there a better way to do this?) > > If I use either of the two options cited above, I feel compelled to add lots > of explanatory comments, because it's not clear to future code maintainers > that the reason I'm doing these things is to prevent culling from happening. > > In the presence of vertex and geometry shaders that do their own > transformation, it seems like others could run into this same issue. I don't > care whether there's an OSG code change or not, but wanted to mention the > issue for consideration by others, future archive searches, etc. > -- > Paul Martz > Skew Matrix Software LLC > _http://www.skew-matrix.com_ <http://www.skew-matrix.com/> > +1 303 859 9466 > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
