Hi Robert,
I was running into the "problem" that I think Jason is trying to address with
his patch. In fact, I was writing a long response explaining how I was hitting
this "bug"... then I realized that getCameraContainingPosition() (and
requestWarpPointer() which calls it) accept "master cameras window/eye coords".
Is this the same as "master camera's context coordinates" (i.e. the coordinate
system that Viewports are specified in)? If so, then I would say that there is
a bug and Jason's fix is valid. If these coordinate systems are the same, I can
send more information elaborating on what the problem is.
If these coordinate systems are different, I would really like to know how to
convert from context coords to "master cameras window/eye coords". I am
currently crawling through the "self documenting" (a.k.a. "self obfuscating")
code trying to divine why/how/where GraphicsWindow and/or
CompositeViewer/Viewer perform this conversion.
It seems strange that "->getEventQueue()->mouseMotion(x, y)" would expect
different coordinate systems depending on whether the GUIActionAdapter you are
using is a GraphicsWindow or a osgViewer::View... which seems to be the case
based on the coordinate conversion that seems to happen with GraphicsWindow
events... which allows getCameraContainingPosition() to work properly when
requestWarpPointer() it is called using max/min values that have been massaged
by GraphicsWindow/Viewer event processing. I don't know... to be honest, I'm
just really confused and frustrated.
-Brad
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43334#43334
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
