After double checking it looks like the sanity check of my analysis actually did work after all.
I've outfitted the osgviewerQT example to illustrate the issue.
Andy
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Robert Osfield
Sent: Sun 6/22/2008 1:21 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] View::computeIntersections Bug
withGUIEventAdapter::Y_INCREASING_DOWNWARDS?
Hi Andy,
The support for mouse coordinates is rather complicated by support for
multiple graphics contexts, and multiple windowing systems. If there
is a bug it is unlikely to be a general problem - as examples like
osgpick and the camera manipulators are all working well - suggesting
that mostly the mouse coordinate system are working together just
fine.
So to work out when you think there is a bug could you please example
what viewer combination you are using, and what values you are sending
to the computeIntersections.
Robert.
On Sat, Jun 21, 2008 at 11:32 PM, Somerville, Andrew
<[EMAIL PROTECTED]> wrote:
>
> 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
<<winmail.dat>>
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
