Half-baked API (Camera position)

[Pavel Safrata]

On 16.10.2013 17:03, Stephen F Northover wrote:
> Could do something useful with what was there now?  We can always fix 
> this in future by adding another API to govern the interpretation of 
> the value.

Not much useful. Anyway, any such stuff can be quite easily done by 
reading the intersectedPoint's Z coordinate.

>
> Throwing the exception indicates that the call is unsupported, but 
> application code can be written to catch the exception and when we 
> implement the API, it can break (I realize that this is unlikely).

The exception can tell by the message that the operation will be 
supported in the future.

Pavel

>
> Steve
>
> On 2013-10-16 10:46 AM, Richard Bair wrote:
>> My quick vote would be throwing the exception, but is like to hear 
>> from Steve and Kevin.
>>
>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata 
>>> <pavel.safrata at oracle.com> wrote:
>>>
>>> Hello,
>>> it looks like we can't help releasing a not-fully-baked piece of API 
>>> with FX8. We've added bunch of new APIs for 3D and did our best to 
>>> make them work well. Unfortunately, there's been not enough 
>>> time&priority to fine-tune their behavior in 2D world. Right now I'm 
>>> concerned about camera position in scene. It is inherent in the 3D 
>>> perspective camera that it has its specific position in world, but 
>>> the 2D parallel camera as we have it projects everything to the XY 
>>> plane basically by ignoring the Z coordinate, so the camera position 
>>> doesn't matter all that much. However, some of the newly added APIs 
>>> depend on it:
>>>
>>> 1. Near/far clip on camera. This obviously cannot work without 
>>> knowing where the camera is. Right now the parallel camera does no 
>>> clipping though, so I guess we are OK to go with it as a "known 
>>> limitation".
>>>
>>> 2. PickResult on events which reports "intersectedDistance" between 
>>> the camera and the picked point. This is worse because we can't just 
>>> "not support" it - there will be some value and once somebody uses 
>>> it we'll have a backward compatibility issue. The state right now is 
>>> that the camera is (tentatively, by my arbitrary decision) at [0, 0, 
>>> -1] and reports distances from there (note that as the camera 
>>> renders everything, for nodes "in front of Z=-1" it reports negative 
>>> distances). This may change when the camera position is properly 
>>> discussed and specified.
>>>
>>> Note that this post is *not* meant to discuss the camera position. 
>>> Even if we could find the answer quickly (which I doubt), it's most 
>>> probably too late to apply the change for FX8.
>>>
>>> So finally here is my question: do you think it's OK to solve this 
>>> by keeping the current behavior and documenting the 
>>> "intersectedDistance" in a way that for parallel camera the numbers 
>>> are unspecified and subject to change in future versions? Or would 
>>> you prefer something more drastic like throwing an 
>>> UnsupportedOperationException (losing the possibility to compare the 
>>> distances)?
>>>
>>> Thanks,
>>> Pavel
>