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 >>> >> >> >
manipulator_patch.tgz
Description: GNU Zip compressed data
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
