Hi Robert, Thanks for your ideas.
At the beginning I found osgWidget quite confusing because of the many API functions and the few documentation :-), especially the WindowManager and its managing functions. In 3D I had to use my own RenderBins settings because the way the WindowManager uses or not uses Bins and depth testing is fine for the ortho camera, but didn't work for me in 3D because of the low (or no) difference in Z coords for the window's background quad and the osgText quads for the letters. A polygon offset helped, but there still were some artefacts. The combination of the original 2D usage and 3D also works fine for me so far, but like I said I had to do e.g. submenu placing a little bit more complicated than in the osgwidgetmenu example. The good thing is, that all the osgWidget's picking functions and mouse callbacks (highlighting buttons when hovering, clicking, keyboard input) are working fine out of the box (at least if you give the handlers high priority), so I don't have to care about mapping coordinates or something like that. In the beginning I also thought of implementing some own sort fo GUI with a textured quad as you said, but I wanted to give osgWidget a try a since for using it as a HUD it's already really good. But perhaps you could help me with a smaller issue that is actually a general question: The WindowManager uses Viewer::computeIntersection to pick the widgets (and actually only returns the first element in the intersection list without further checkings) but it always picks the 3D widgets first. So generally the picking order is: 3D widgets, 2D widgets, and at last the scene (due to the order of the handlers). But I can't figure out why the 3D widgets are picked first. What effects the traversal order (or actually the result order) for calculating intersections? I have the 3D widgets in a Group beside the ortho camera with the WindowManager and its widget nodes. The 2D widgets should have Z coords like 0.15 or something like that, but neither Z nor the order in which I add the nodes to the scene graph changes the picking result. The only thing I could think of is that the fact that I have the perspective main camera and the ortho camera effects the order (I think there was something like getCameraContaining(Node*) in some part of the code....?). _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
