Hi Robert and Rui, I have finished one big topic in my work and before I dive into another, I might take a look once again on the design pattern issue in my previous RayIntersector submission (unless someone else wants to take care about it).
My idea would be to have one class as an adapter (staying in the place of the current LineSegmentIntersector) while this adapter will forward all the calls to a real intersector class. There will be two intersector classes - one for line intersections, the second for ray intersections. The adapter will create the first or the second intersector based on the need of an user. This may be recognized from, for instance, method parameters or used methods. My idea would be: If user uses Vec3 constructors and Vec3 methods, let's use line intersections, and if he uses homogeneous coordiates (Vec4), let's use ray intersections. Another option would be to let the user specify which intersector he wants (with default set to line intersector). Thoughts? Other ideas? Giving it more thinking: Anyway, what will we get by these design patterns? We would need to change code throughout OSG to not use LineSegmentIntersector, but our adapter. Another problem: Line intersector may change to RayIntersector during the scene graph traversal because a transformation matrix in Camera or Projection, or even Transform may transform the points to infinity. One option is to have only one intersector class that would use faster 3D-code when possible, and slower homogeneous code otherwise. Other option would be to have both intersectors and to update LineSegmentIntersector::clone() to create RayIntersector whenever _start or _end were transformed to infinity while LineSegmentIntersector will be used in regular cases. The same for RayIntersector::clone(). The last design problem is that LineSegmentIntersector and RayIntersector can not be derived from each other as one is carrying _start and _end as Vec3 and the other as Vec4. If we do not mind to waste few bytes, or if we do not mind to store Vec3 + separate float for w component, we could do that. Otherwise, we will need an abstract class for code sharing between the two intersection classes. The code sharing involves: five methods (~200 lines of code), Intersection struct containing the result of the intersection (the struct should be the same for both intersectors, IMHO, to avoid easy switching between the classes) and TriangleIntersection struct (~200 lines of code). Thoughts? John On Wednesday 13 of February 2013 16:33:21 Wang Rui wrote: Hi Robert, I'd like to submit my changes to fix the "near/far values for intersection" problem, which can be obviously found in osgdepthpartition and osgpick (with the option --relative-camera-scene) examples. In the osgdepthpartition example, we can't actually perform correct intersection test (in WINDOW/VIEW/PROJ coordinate frames) with earth/sun nodes because the necessary near/far values are stored in slaves instead of the main camera. I provide a new computeGlobalNearFar() method in ViewerBase to obtain a global near/far pair and apply it to the main camera, and update the osgdepthpartition example to show how it works. In the osgpick example with --relative-camera-scene, you will see that when picking the cube object, only one result is returned (but of course there should be two). That's because the cube is drawn under a post camera in the scene graph. The CullVisitor will reset old near/far values every time when it finishes traversing a child camera, so the depth data of the cube is already lost when we apply getCalculatedNearPlane() and getCalculatedFarPlane() to the main camera in SceneView::cull(). I changed this behavior by providing the getGlobalNearPlane()/getGlobalFarPlane() methods, and now osgpick can work with correct results. The computed result may not satisfy everyone as it collect all perspective projection matrices to get a global near/far pair. But in some cases we may want to ignore some of them (e.g., RTT camera matrices). This can be done by providing an extra option to the Camera/Projection classes. But at least my changes should not affect the rendering work and should be compatible with most current applications. So I'm glad to submit them now. :-) Some months ago, you, PCJohn and me discussed about the idea of infinite line intersection (seems that for design pattern reason the RayIntersector is not merged to the trunk yet). It could also fix the intersection problem in large environments. But the correct near/far values are still not returned to users, which may be very useful for debugging and implementing frustum-related algorithms. I hope this patch could help. Cheers, Wang Rui
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
