[API Review] RT-28129: event coordinates with perspective camera

[Kevin Rushforth]

I think the PickRay would be a good addition when we provide a 
user-initiated picking API that takes a PickRay provided by the user 
(right now picking is only done as part of the mouse event handling 
system). Until then, this is probably not needed, although as Pavel 
indicated, could be added pretty easily.

Chien: what do you think?

-- Kevin

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 
>> touch/click...
>
> I'll let people with more 3D background decide. From the technical 
> point of view, it can be added quite easily.
>
>>
>> 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.
>
> Pavel
>
>>
>>             ...jim
>>
>> On 2/1/13 8:51 AM, Pavel Safrata wrote:
>>> Hello,
>>> 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.
>>>
>>> http://javafx-jira.kenai.com/browse/RT-28129
>>>
>>> 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 
>>> the
>>> 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 
>>> ones.
>>> 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:
>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI
>>>
>>> Thanks,
>>> Pavel
>>>
>