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

[Pavel Safrata]

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