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

[Chien Yang]

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