Hi Robert and Rui, there is still one design problem unanswered and that is integration of RayIntersector. Actually, I do not care about RayIntersector as long as CameraManipulators works correctly. I am not ray-picking anything (currently), but CameraManipulators does not work for infinite scenes (very sad for me). Thus, CameraManipulators are not compatible with ShadowVolume techniques.
One natural solution would be to use RayIntersector in CameraManipulators. Another approach would be to provide Factory or Prototype approach to let the programmer choose the type of intersector. Would that be an acceptable approach or you prefer something else? John On Friday 15 of February 2013 20:10:38 Wang Rui wrote: Hi Robert and John, 2013/2/15 Robert Osfield <[email protected]> have scene graphs that embed Camera's and need an unbounded ray intersection then they should use a RayIntersector from the start. So that's why I'm submitting this patch, which in my opinion can solve the near/far problem for cameras in scene graph. :-) Robert, you may review it and discuss if it is appropriate for the trunk with me when you have time. I agree that there can be two classes: LinesegmentIntersector and RayIntersector. It is the users who will need to care about which to choose. And having two different intersectors will help differentiate which kind of intersection test we just made. People may directly write code with a new RayIntersector instance if they need to do so, instead of using viewer.computeIntersections(). In most cases I don't see too much efficiency difference of the two (if we can solve the near/far problem caused by slave and embedded cameras this time) so maybe it is not a question for the viewer itself to automatically decide which one must be used. Thanks, Wang Rui
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
