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

[Richard Bair]

Sure

On May 17, 2013, at 8:31 AM, Pavel Safrata <pavel.safrata at oracle.com> wrote:

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