Hey for a long time I've seen behavior where, if I attempt to use
View::computeIntersections before sending any input to the eventQueue, the Y
value seems to be inverted. I.e. attempts to pick at the bottom of the screen
return results from the top of the screen. This would happen at startup before
any mouse input had been forwarded to the viewer. I tried to figure it out when
I was still a newbie and gave up since there are several easy workarounds
(programmatically simulate a mouse event, etc.) and I figured I was just doing
something wrong.
Recently when cleaning up some code I figured I'd give it another try, and I
think I may have found the source of the problem.
- osgViewer::View::computeIntersections calls
osgViewer::View::getCameraContainingPosition
- which as a side effect provides transformed "local_x", and "local_y".
- depending on getEventQueue()->getCurrentEventState()->getMouseYOrientation(),
Y can be inverted in the transformation
- EventQueue's constructor's default arg sets mouseYOrientation to
GUIEventAdapter::Y_INCREASING_DOWNWARDS
- osgViewer::View creates it's eventQueue with no arguments thus has
mouseYOrientation Y_INCREASING_DOWNWARDS
- EventQueue sets its GUIEventAdapter _accumulateEventState
(getCurrentEventState) mouseYOrientation from the orientation passed to its
constructor
- thus by default View::computeIntersections will invert y
- until in Viewer::eventTraversal(), upon a "pointerEvent",
eventState->setMouseYOrientation(osgGA::GUIEventAdapter::Y_INCREASING_UPWARDS)
is called
- (setMouseYOrientation does not seem to be called anywhere else in Osg, so the
value cant seem to change otherwise)
So it seems that it is a bug considering that the start state is always
Y_INCREASING_DOWNWARDS and upon any pointer input, always gets set to
Y_INCREASING_UPWARDS without regard to any other parameters or conditions.
However I can't completely confirm all of this as my hack fix to prove the
analysis failed. To prove to myself that this is the issue I call
"viewer->getEventQueue()->getCurrentEventState()->setMouseYOrientation(
osgGA::GUIEventAdapter::Y_INCREASING_UPWARDS )" which should negate the
problem, and it seems that it doesn't.
Can anyone:
- confirm that they have seen this issue before themselves?
- confirm that my analysis is (in)correct ?
and/or
- tell me if/where I got something wrong ?
Thanks,
Andy
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
