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

[Richard Bair]

Do we want to continue that tradition? There is a long history of crappy names in C APIs, not all of which we brought with us to Java :-)

Richard

On Feb 1, 2013, at 11:12 AM, Chien Yang <chien.yang at oracle.com> wrote:

> Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ),  and glTexCoordPointer(4,GL_FLOAT,0,0).
> 
> - Chien
> 
> On 2/1/2013 11:01 AM, Richard Bair wrote:
>> Only thing that got my attention was: getIntersectedTexCoord
>> 
>> Is the rest of the 3D API using shortened names like "tex" and "coord" as well?
>> 
>> Richard
>> 
>> On Feb 1, 2013, at 10:57 AM, Chien Yang <chien.yang at oracle.com> wrote:
>> 
>>> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives.
>>> 
>>> Thanks,
>>> - Chien
>>> 
>>> On 2/1/2013 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
>>>> 
>>> 
>> 
>