[API Review] RT-28129: event coordinates with perspective camera
chien.yang at oracle.com
Mon Feb 4 08:55:02 PST 2013
On 2/4/2013 2:32 AM, Pavel Safrata wrote:
> Hi Jim,
> On 2.2.2013 5:25, Jim Graham wrote:
>> Would a 3D program need to know the direction the pick ray came into
>> the object from? Knowing the xyz of the location on your surface
>> tells you where they hit your object, and I'm not sure how much they
>> get from the distance, but the direction could tell them whether to,
>> say, apply english to a cue ball as it spins away from the
> I'll let people with more 3D background decide. From the technical
> point of view, it can be added quite easily.
With the PickResult object, a user can construct this direction vector
from the Camera position and the return intersected point.
>> Also, perhaps it goes without saying, but I'm guessing that if you
>> have a regular 2D node then the getZ() would be 0 because it
>> represents the touch point that was transformed into your local
>> coordinate system which is a plane?
> It will be 0 when delivered to the event target. However, not
> necessarily during the capturing/bubbling phases. For example, if you
> have a rectangle in a group, and the rectangle has setTranslateZ(10),
> the event will have z=0 when delivered to the rectangle, but z=10 when
> delivered to the group.
>> On 2/1/13 8:51 AM, Pavel Safrata wrote:
>>> this is related to the 3D support planned for FX8, yet it is a
>>> bugfix of
>>> an existing issue.
>>> With perspective camera, events delivered to any node that's not lying
>>> flat on the XY plane contain wrong local coordinates - they ignore the
>>> projection transformations. It's enough to rotate a rectangle along X
>>> axis and the coordinates become useless.
>>> Solution to this problem requires API changes, because we need to
>>> compute in 3D to get proper numbers. So I propose to add a "double
>>> getZ()" method to all picking-based events, with the following
>>> semantics: the event's getSceneX(), getSceneY() values still represent
>>> the 2D coordinates of the mouse in the window content pixels (screen
>>> coordinates minus window position and decorations); the getX(), getY(),
>>> getZ() represent the hit point in the local 3D space (which may now be
>>> different even for scene because of the perspective transform). If no
>>> node is picked, the hit point with the scene will be found on the
>>> projection plane. Note that nothing changes for the 2D case, for the 3D
>>> case we now have correct 3D coordinates instead of a complete nonsense.
>>> There is one more issue - how to pass the correct coordinates to the
>>> event constructors. Instead of creating more construrctors with the
>>> three additional coordinates, I propose to use a concept called
>>> PickResult which was briefly discussed earlier and will soon be part of
>>> a 3D API review. In short, it is an object that contains information
>>> about the pick for the event - the picked node, local coordinates of
>>> hit and some 3D-specific stuff. For proper 3D support, it will
>>> anyway be
>>> necessary to pass the PickResult to the events and allow access to it;
>>> once this is done, the event can compute the coordinates from it. So I
>>> propose adding PickResult to the event constructors. Note that they've
>>> not been released yet, so we can modify them instead of adding new
>>> Also note that for convenience of 2D use-cases, the constructors will
>>> accept a null PickResult and in this case compute PickResult values
>>> based on the passed event target and scene coordinates (which is
>>> sufficient for 2D case).
>>> Side note for those who remember the previous 3D API discussion: the
>>> PickResult is no longer restricted to 3d shapes, it is present always,
>>> with the 3D-specific fields having null values where not applicable.
>>> Summary of this proposal:
>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent,
>>> ContextMenuEvent and TouchPoint
>>> new methods: getZ(), getPickResult() (and extended semantics of event
>>> local coordinates for 3D case)
>>> modified methods: added PickResult to all constructors
>>> Concrete description of the PickResult and the proposed picking API can
>>> be found here:
More information about the openjfx-dev