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

Chien Yang 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 
>> touch/click...
>
> 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.

- Chien

>
>>
>> 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
>>>
>



More information about the openjfx-dev mailing list