Hi Robert, We noticed an issue with COMPUTE_NEAR_FAR_USING_PRIMITIVES mode. I have prepared simplified .osg example scene which shows the problem. File could be tested with slightly modified osgviewer. Modification is required to turn on proper near/far mode. Adding following line does this: viewer.getCamera()->setComputeNearFarMode( osg::Camera::COMPUTE_NEAR_FAR_USING_PRIMITIVES );
Once loaded into viewer simply move camera forward and you will notice that bottom triangle dissapear and notification message is printed in console. Message warns about negative near plane candiate which is rejected by CullVisitor. 4:3 frustum proportons are important here and its neccessary to run in one screen. If run on two screens (8:3) problem does not show. Example file contains two geodes, each with one drawable, stored in two branches with pair of Transforms as root and parent of first geode. One of these drawables is sphere and second is very sharp long triangle (selection of drawables is not really imporant) It turns out that when code fails, near plane is computed based on distance to far located sphere instead of much closer triangle. I investigated this case and noticed that problem is related to cliping plane mask stack management by CullVisitor frustum. It happens when osg::Polytope::_resultMask (mask which stores bits corresponding to clipping planes intersecting node/drawable) is not restored after traversal to first subbranch of scene tree. When cull traversing next subbranch, call to push clipping mask on the mask stack pushes empty mask and consecutive culling of drawable assumes that drawable entirely fits into viewing frustum which in turn causes above computation error and message warning. I am sending modified osg/Polytope include file. There are actually two places where I changed the code. I am leaving it to your judgment which one is better. It may be reasonable to appy them both if they don't break some other OSG code. Problem with selecting proper fix is that I am not sure where the source of the problem actually is. There seems to be design assumption that _maskStack cannot be empty as all osg::Polytope::contains() methods call _maskStack.back() without any checks. But usually when cull traversal starts it is initially empty. Code works (most of the time) beacause _maskStack is based on fast_back_stack template which always have _value field accesible using fast_back_stack::back() method. While it does not produce sig_fault, it can return random values when maskStack is not initialized. osg::Polytope::setupMask() method overcomes this problem by direct assignment of initial clipping mask to _maskStack.back(). But as the above example shows this _maskStack.back() will be lost when some action in CullVisitor changes _resultMask between pushCurrentMask/popCurrentMask combo calls. Cheers, Wojtek Lewandowski
near6lcs.osg
Description: Binary data
Polytope
Description: Binary data
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
