Hi Rui, Sorry for the slow review on this submission. I've just merged and had a play with various models I have and while it functions I find that is a bit jarring to use as the movement can suddenly stop at movements you don't expect. For this type of functionality to work well I think one has to add some form of elasticity into the movement and to support deflection along a tangent so that if you are panning/or gliding towards something you don't just halt as if you've hit a solid way. Such a sophisticated behaviour is not easy to implement, and probably is something that is quite manipulator specific. I do however feel that it needs to solved as I don't feel the proposed changes feel natural to use.
In general I do wonder if pushing too much functionality into osgGA manipulators is self defeating. Camera manipulation can be quite domain specific and it may be better for us to just make it convenient for users to roll their own camera manipulators, rather than adding ever more complicated camera manipulator implementations that almost but not quite do what end users need and then are too complex for them to understand how they modify them to work how they need. In future rev's of osgGA I'd like to do less on the camera manipulator front rather than more. So for now I don't feel your changes are taking osgGA in the direction it should go. Thanks, Robert. On 21 June 2012 09:07, Wang Rui <[email protected]> wrote: > Hi Robert, > > I just tried write a simple collision test for use when manipulating in the > scene. It could prevent viewer from going through buildings and terrain > models, which may be uncomfortable for end-users. To write a perfect > collision function, we may need the help of physics engines. But my cheap > solution will not depend on any other libraries, instead I implement a > sphere-box intersection test, as well as a sphere-triangle intersection test > for StandardManipulator, and will simply replace the manipulator attributes > into previous ones if there are something collided with a virtual sphere > around the eye. This can work for all Orbit/FirstPerson manipulators, and > won't be too slow because of not really calculating intersection points (but > only check if they are intersected). > > You may enable collision quickly using an env variable: > # export OSG_INTERSECTION_RADIUS=5 > # ./osgviewer lz.osg > > Or use the added APIs: setIntersectionRadius() and setIntersectionMask() to > do the same work. > > Future improvements could make the motion after collided more smoothly > rather than suddenly stopped. But I hope this initial work could be a start > of more realistic scene navigation. > > Cheers, > > Wang Rui > > > > _______________________________________________ > 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
