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

[Pavel Safrata]

Richard, are we OK with 3D versions of localToScreen and no 3D versions 
of screenToLocal? Can I still consider the API approved?
Thanks,
Pavel

On 14.5.2013 7:55, Chien Yang wrote:
> Hi Pavel,
>
>     Kevin and I did chat about this briefly today. We agree that it is 
> better to remove the 3D version of screenToLocal for now.
>
> Thanks,
> - Chien
>
> On 5/13/2013 8:33 AM, Pavel Safrata wrote:
>> So it looks like there is no straightforward solution right now. So, 
>> should I remove the screenToLocal3D methods from the proposed API? 
>> The localToScreen can still be added without problems for the 3D 
>> case, there just wouldn't be any screenToLocal for 3D, justified by 
>> the fact that you actually need to do some form of picking for the 
>> conversion (and picking is not public yet). The screenToLocal(Bounds) 
>> would have to be documented to provide reasonable result for 2D 
>> scenes only.
>> Thanks,
>> Pavel
>>
>> On 7.5.2013 15:42, Pavel Safrata wrote:
>>> 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?
>>>>>>>>>>>
>>>>>
>>>>>
>>>
>>
>