I forgot to reply about osgpick and the manipulators... I may not have been clear originally: This issue only happens on a fresh viewer, before any mouse input has happened. So it is expected that osgPick will not have a problem, as osgPick always uses computeIntersections via a pointerEvent which itself resolves the issue. Camera manipulators probably don't use the offending osgViewer::View::getCameraContainingPosition unless through a pointer event which again by nature solves the issue.
The only way that this would be expected to show up is if someone is using
computeIntersections (or anything that uses getCameraContainingPosition) at the
very beginning of an application before any mouse input would have reached the
viewers eventQueue, which is how I ran into it.
A simple example might be if someone was programatically determining if a
particular object is in a certain quadrant of the screen.
You can see a similar situation in the osgviewerQT example I posted.
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
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
<<winmail.dat>>
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
