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
