[API REVIEW] RT-30171: 3D versions of localToScreen and screenToLocal

[Pavel Safrata]

In 3D the point in screen coordinates doesn't correspond to any specific 
single point in local coordinates because the of the projection. The 2D 
screen point casts a ray to the 3D space of the scene (and the node). 
This ray might not even have any common point with scene's or node's XY 
plane. In other words, between the screen point and local point is a 
non-invertible projection transform so in this direction we can't simply 
transform the point to another point.
Thanks,
Pavel

On 7.5.2013 13:19, Kevin Rushforth wrote:
> I doubt that we should mix intersection (picking) with a simple 
> transformation method. I would expect screenToLocal to take a point at 
> the Z=0 plane in window/screen coordinates and return the transformed 
> point in local coordinates.
>
> -- Kevin
>
>
> Chien Yang wrote:
>> Hi Pavel,
>>
>>      Can you fill me in on what is the use case for doing the 3D 
>> extension for FX 8?
>>
>> Thanks,
>> - Chien
>>
>>
>> On 5/6/2013 5:04 PM, Richard Bair wrote:
>>> I'm out of my depth, relying on Kevin & Chien to say something smart 
>>> :-)
>>>
>>> On May 6, 2013, at 7:02 AM, Pavel Safrata <pavel.safrata at oracle.com> 
>>> wrote:
>>>
>>>> Hello,
>>>> I need to reopen this for additional clarification. The question is 
>>>> - what exactly does the screenToLocal do in 3D?
>>>>
>>>> My original intent and still my favorite approach is:
>>>> - if the node contains (is present on) the specified screen 
>>>> location, return the intersection point like in picking
>>>> - otherwise, return the point on projection plane transformed to 
>>>> node's local coordinates
>>>>
>>>> It seemed natural - you'd get the local coordinates of the node's 
>>>> point rendered on the given location, where possible. But then, it 
>>>> is a method for transforming coordinates, how do we know user wants 
>>>> intersection with the node itself? Maybe he wants always 
>>>> intersection with the projection plane or even with something else. 
>>>> The correct approach would probably be returning the (local) ray 
>>>> and let the user obtain any desired intersection. This can't be 
>>>> done right now, the picking&ray&intersection features are not 
>>>> public yet and won't be for this release. So we can either remove 
>>>> screenToLocal3D for now or specify the intersection point it 
>>>> returns, where I can see two options: either do it as described in 
>>>> the beginning of this email, or always intersect the projection 
>>>> plane. I'm not sure if the projection plane intersection is very 
>>>> useful, but the results would be more consistent (wouldn't jump 
>>>> elsewhere on the edge of the node).
>>>>
>>>> It becomes even a bit more complicated with screenToLocal(Bounds), 
>>>> which is there, works in 2D and needs to be extended to 3D (or 
>>>> removed). The only approach I can imagine is using screenToLocal on 
>>>> the four vertices and construct 3D bounds that contain all of them, 
>>>> but I admit I'm not sure the result is useful at all.
>>>>
>>>> What do you think?
>>>> Thanks,
>>>> Pavel
>>>>
>>>> On 3.5.2013 16:56, Kevin Rushforth wrote:
>>>>> Check out the subject of the message.  ;-)
>>>>>
>>>>> RT-30171
>>>>>
>>>>>
>>>>> Richard Bair wrote:
>>>>>> What's the JIRA issue so I can mark it?
>>>>>>
>>>>>> On May 2, 2013, at 11:15 PM, Pavel Safrata 
>>>>>> <pavel.safrata at oracle.com> wrote:
>>>>>>
>>>>>>> These methods were not released yet so we would not break 
>>>>>>> compatibility with anything except of several weekly builds back.
>>>>>>> Anyway, I agree with Richard's proposal.
>>>>>>> Pavel
>>>>>>>
>>>>>>> On 3.5.2013 0:02, Ali Ebrahimi wrote:
>>>>>>>> +1.
>>>>>>>> Breaking (source & binary)compatibility is not good thing.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, May 3, 2013 at 2:21 AM, Richard Bair 
>>>>>>>> <richard.bair at oracle.com> wrote:
>>>>>>>> Hi Pavel,
>>>>>>>>
>>>>>>>>> // these two already exist:
>>>>>>>>> public Point2D localToScreen(double localX, double localY)
>>>>>>>>> public Point2D localToScreen(Point2D localPoint)
>>>>>>>>> // these two exist but without the 2D suffix, so rename them 
>>>>>>>>> (they were added in FX8 so no backward incompatibility):
>>>>>>>>> public Point2D screenToLocal2D(double screenX, double screenY)
>>>>>>>>> public Point2D screenToLocal2D(Point2D screenPoint)
>>>>>>>>> // add these four for 3D
>>>>>>>>> public Point2D localToScreen(double localX, double localY, 
>>>>>>>>> double localZ)
>>>>>>>>> public Point2D localToScreen(Point3D localPoint)
>>>>>>>>> public Point3D screenToLocal3D(double screenX, double screenY)
>>>>>>>>> public Point3D screenToLocal3D(Point2D screenPoint)
>>>>>>>> Just mulling it over. What about:
>>>>>>>>
>>>>>>>> // these two already exist:
>>>>>>>> public Point2D localToScreen(double localX, double localY)
>>>>>>>> public Point2D localToScreen(Point2D localPoint)
>>>>>>>> public Point2D screenToLocal(double screenX, double screenY)
>>>>>>>> public Point2D screenToLocal(Point2D screenPoint)
>>>>>>>> public Point2D localToScreen(double localX, double localY, 
>>>>>>>> double localZ)
>>>>>>>> public Point2D localToScreen(Point3D localPoint)
>>>>>>>> public Point3D screenToLocal3D(double screenX, double screenY)
>>>>>>>> public Point3D screenToLocal3D(Point2D screenPoint)
>>>>>>>>
>>>>>>>> In this case we only append the "3D" to screenToLocal variants 
>>>>>>>> that produce Point3D?
>>>>>>>>
>>
>>