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

[Kevin Rushforth]

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