On 20 November 2015 at 13:42, Jannik Heller <[email protected]> wrote:
> > Invalid bounding sphere's disabling culling is deliberate design. It's > for cases where you can't determine the bounding volume and therefore can't > determine how to cull them as culling is predominantly based on a knowledge > of the bounding volume. > > > > > fair enough but as I demonstrated this design does not work correctly. > Once you merge an invalid bounding sphere with a valid bounding sphere of a > sibling, the overall bounding sphere becomes valid and thus setting an > invalid bounding sphere to circumvent culling does not even work reliably. > > For nodes you don't want culled you simply do "setCullingActive(false)", > which works reliably, unlike the indeterminate bounding sphere way. I don't > see why we need two features doing the same thing with one being slightly > broken. > The official route is using CullingActive to disabling culling, the disabling of culling via a invalid bounding sphere is simply a consequence of there is valid interpretation of invalid bounding volume so the only safe thing to do is not cull it. The bounding volume computation for a group that contains both invalid and valid children bounding volumes presents a dilemma. The current implementation takes in to account only valid bounding volumes, this isn't ideal for all circumstances of course. Whatever you do with this type of problem is not full proof. > > Changing either behaviour will break existing OSG applications that rely > upon this. > > Understood, but as I said we can add a new culling option that is off by > default if the compatibility issue is too much of a concern. > > Maybe another way to approach the issue would be marking bounding sphere's > as a "null" bounding sphere as opposed to an invalid one. Unfortunately I > can't think of a way to do so without adding overhead to each bounding > sphere intersection test. Adding extra complexity for a niche problem - ideally you don't have scene graphs with invalid bounding volumes, just occasionally do they come in useful to help defer a computation or work around a problem of not being able to compute the bounding volume. For your own task I suspect the solution will not be to change the core, but to address the problems so you don't generate scene graphs in a indeterminate state. Robert.
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
