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.safr...@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

Reply via email to