Transform point using localToSceneTransform

[Pavel Safrata]

On 1.8.2012 18:01, Pavel Safrata wrote:
> On 28.7.2012 0:06, Richard Bair wrote:
>> Vector3D extends Point3D?
>
> No. Vector is not point and point is not vector. As Kevin suggested 
> they may have a common parent - Tuple.
>
> Here is the list of things that currently use Point3D as a vector (all 
> of them on class Rotate):
>
> X_AXIS, Y_AXIS, Z_AXIS
>     we would have to deprecate those and define different ones with 
> some uglier names
>
> Rotate(double angle, Point3D axis)
> Rotate(double angle, double pivotX, double pivotY, double pivotZ, 
> Point3D axis)
>     we would have to deprecate those and overload them with another 
> ones taking Vector3D
>
> Point3D getAxis()
> void setAxis(Point3D value)
> ObjectProperty<Point3D> axisProperty()
>     this is the biggest issue, even if we wanted to deprecate the 
> property I don't know what name could have the new one, also we would 
> have to maintain them both, bound to each other, until the old one is 
> removed.
>

And on Node:
void setRotationAxis(Point3D value)
Point3D getRotationAxis()
ObjectProperty<Point3D> rotationAxisProperty()

I've been thinking about this over and over and I'm not happy to say 
that I think I'm starting to change my mind. As I'm still completely 
convinced that separating vector from point is the right thing to do, in 
our situation it would nearly destroy our rotation API (which is very 
unfortunate because axis is not point in any sense! - But at least its 
name is now 'axis'). I don't like merging the two species in Point3D but 
at least this way we can do our best to minimize the damage by designing 
the new API somehow sensitively..

Pavel

> This is quite a serious argument against separating point and vector.
>
> Looks like on one side we have ugly Rotate with some deprecated stuff, 
> on the other side we have ugly Point with nonsense methods and a bit 
> ugly methods in Affine. I still vote for separating because ugly 
> property name seems lesser evil than wrong concept and weird method 
> names. Anyway, this is a backward compatibility issue and Richard will 
> probably have the final word here.
>
> Pavel
>
>>
>> On Jul 27, 2012, at 2:19 PM, Jim Graham wrote:
>>
>>> This is starting to make sense to me as I see more examples of how 
>>> the 2 are used.  I'm definitely seeing the value of separate types 
>>> for making code readable and for encouraging proper math.  It's like 
>>> making our geometry code "strongly typed" - in the Java spirit...
>>>
>>>             ...jim
>>>
>>> On 7/26/2012 7:35 AM, Pedro Duque Vieira wrote:
>>>> Hi again,
>>>>
>>>>
>>>>> Hi Kirill,
>>>>> On 26.7.2012 10:10, Kirill.Prazdnikov wrote:
>>>>>> On 26.07.2012 10:20, Pavel Safrata wrote:
>>>>>>> Exactly, I think the point is that 'point' is not 'vector' 
>>>>>>> regardless
>>>>>>> of what workarounds we introduce in method naming and 
>>>>>>> documentation.
>>>>>>> Those methods would look really weird on Point.
>>>>>> Both are from the same R3 space, right ?
>>>>> Right.
>>>>>> And we can add them together :
>>>>>>   Vector speed, position;
>>>>>>    position += time * speed;
>>>>>>
>>>>>> I vote for Jim`s approach.
>>>>> Does it make sense to add two points? I think it doesn't. So if we 
>>>>> have
>>>>> Point and Vector, we need something like Point.add(Vector) or
>>>>> Point.shift(Vector). In Jim's approach we need Point.add(Point) with
>>>>> documentation stating that one of the points represents a point 
>>>>> and the
>>>>> other one represents a vector. So what is the advantage?
>>>> Exactly. Adding two points doesn't make sense.
>>>>
>>>>
>>>>
>>>>>> If a transform is { M3x3 + Translate }, them
>>>>>>   - transformPoint (normal transform) would be { P*M3x3 + 
>>>>>> Translate }
>>>>>>   - transformVector (delta transform) would be { P*M3x3 }
>>>>> We already know that it is possible to represent both things by one
>>>>> class and move the distinction to method names and documentation. But
>>>>> please explain what is the advantage of it (except the obvious one of
>>>>> having lower class count).
>>>>> Thanks,
>>>>> Pavel
>>>>>> -Kirill
>>>>
>>>> If you go this way with point you could go this way with a lot of 
>>>> other
>>>> framework classes: say you could use Point2d to represent a 
>>>> Dimension2d, a
>>>> BoundingBox to represent a Rectangle2D or Insets, etc.
>>>> I personally don't really think this is a good approach.
>>>>
>>>> Thanks, best regards,
>>>>
>
>