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

[Pavel Safrata]

Richard? I'm ready to push, waiting for your re-approval.
Thanks,
Pavel

On 15.5.2013 15:14, Pavel Safrata wrote:
> 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?
>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>