HI David, Sorry for the delay on review of your latest changes. I've just done a review and mostly everything looks ready to merge. One area that needs some more work is the way that you register the locally defined RenderBin - I think this is over complicated, and it should be sufficient to just reuse the osgUtil::RegisterRenderBinProxy, by wrapping up the RenderBin creation in a function call made from the proxy construction. I will have a tinker at my end to see if I get get this to work.
Robert. On Tue, May 5, 2009 at 12:14 PM, David Callu <[email protected]> wrote: > minor fix in typo. > > Cheers > David > > 2009/4/29 David Callu <[email protected]> >> >> Hi Robert >> >> Problem: >> osgManipulator::Dragger is sometime hide by geometry which is dragged. >> >> Solution: >> osgManipulator::Dragger draw one normal geometry and one >> semi-transparent >> without depth test so we always see the manipulator. >> Transparent geometry is draw in special renderbin named >> "ManipulatorRenderBin" >> with the number stage = TRANSPARENT_BIN + 1 >> >> >> Minor fix: >> osgManipulator::CompositeDragger::handle(...) search which Dragger >> (which compose the CompositeDragger) >> is really picked. But this method sometimes return the bad one. now >> fixed. >> >> Current osgManipulator::TabBoxDragger (big white box) in the >> osgmanipulator example reproduce the bug. >> Try to pick each face, on some of them the face picked is the one >> behind the front one. >> >> >> >> Minor refactoring: >> All dragger have a setupDefaultGeometry but not virtual. now it is. >> All Dragger based class (except CompositeDragger based class) >> have color and pickColor properties. Now defined in ColoredDragger >> and inserted in class inheritance hierarchy between >> osgManipulator::Dragger and derived class >> >> I also improve the osgManipulator exemple to show all exiting manipulator >> >> >> all modification is based on SVN trunk 10121 >> >> Cheers >> David >> >> >> 2009/3/13 David Callu <[email protected]> >>> >>> Hi Robert >>> >>> 2009/3/11 Robert Osfield <[email protected]> >>>> >>>> Hi David, >>>> >>>> On Wed, Mar 11, 2009 at 12:52 PM, David Callu <[email protected]> wrote: >>>> > Problem: When I use osgManipulator::Dragger, geometry dragger is >>>> > partially >>>> > hide by the geometry I want to move/rotate/scale/... (image 1 : >>>> > dragger_hide.png) >>>> > To fix this, I render the Dragger geometry in different RenderBin with >>>> > a >>>> > DEPTH_TEST OFF. >>>> > (image 2 : dragger_not_hide.png) >>>> > Put the dragger in different RenderBin is the user responsability. >>>> > >>>> > Currently, PointerInfo check if the first intersection is a dragger, >>>> > if it's >>>> > not one, >>>> > nothing is done. If it's one, dragger mechanism is applied. >>>> > >>>> > Now, I need to search in intersectionList if the second or third or .. >>>> > hit >>>> > is a dragger. >>>> > If it's one, apply dragger mechanism otherwise don't do anything. >>>> > Depth is the variable to specify how many hit must be test to search a >>>> > dragger. >>>> >>>> OK, I think I understand now. >>>> >>>> > If I well understand your last sentence : >>>> > >>>> > "The general approach to solving >>>> > this problem seems awkward, and can't help feel that perhaps the >>>> > dragger intersection code itself would be better off being tweaked so >>>> > that it ignores non dragger geometry automatically." >>>> > >>>> > It's better to check all intersection while there are one, and while >>>> > it's >>>> > not a dragger. >>>> > So the depth variable is useless. >>>> > >>>> > I'm right ? >>>> >>>> My inclination is to just search the list from intersection list from >>>> back to front till a manipulator is hit then return this as a hit. >>>> Although I guess it might well be something you'd want to toggle >>>> on/off, perhaps per manipulator based on whether the manipulator might >>>> be using a visual trick lick the one you've suggested. >>> >>> This seem to be good solution, >>> If the manipulator is an axis base'd manipulator (and not a box or >>> sphere), >>> I add a visual trick like you suggest (one normal and one >>> semi-transparent). >>> Then on intersection test, I search in front to back. >>> If the first hit is a manipulator, return it. >>> otherwise, search in hit list, and if I found a manipulator and it have a >>> visual trick, >>> return it. >>> >>> If I search from back to front like you suggest, and two manipulator are >>> one back the other, >>> I will return the bad one. >>> >>> >>> I'm working on this. >>> More in next episode :-) >>> >>> David >>> >>>> >>>> W.r.t your visuals, displaying the manipulator always on top by >>>> disabling the depth test will break the depth cue of occlusion. My >>>> inclination would be to render the manipulator twice, once with depth >>>> test on, then a second time with depth test off and blending on so >>>> that the colour gets blended with the background colour. This would >>>> make it seem like the geometry is semi-transparent, but with occlusion >>>> still active. >>>> >>>> Robert. >>>> _______________________________________________ >>>> osg-submissions mailing list >>>> [email protected] >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>> >> > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
