Transform point using localToSceneTransform

[Pavel Safrata]

Hi Jim,

On 26.7.2012 4:22, Pedro Duque Vieira wrote:
> Hi Jim,
>
>
>> Hi Pavel,
>> You claim that we need to add new methods if we treat a point as if it
>> were a vector, but we would have to do that anyway to add methods that
>> take vector.
>> So, we can either add:
>>          transform(Vector) - treats its arg as magnitudes
>>             (and thus does a delta transform)
>> or we can add:
>>          deltaTransform(Point) - delta transforms the arg
>>             (which is what you want to do with magnitudes)
>>
> There is a miss conception here. The proposed Vector isn't merely a
> representation of a magnitude, it is a magnitude and an
> angle/direction(although this is not stored internally in the instance) as
> what exists in java3d and has a set of methods to compute/get vector
> related stuff: get vector angle, get vector magnitude, get angle between 2
> vectors, compute cross product between vectors, etc.

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.

> It isn't strictly necessary to do a deltaTransform to transform a Vector,
> one can transform a vector like a point is transformed.
>
>
>> It's a matter of whether the semantics are in the method name or the
>> argument type.
>> Furthermore, an array of doubles does not have an "am I a set of points
>> or vectors" type attached to it so we do need to have 2 different method
>> names for the methods that take arrays of doubles, whether or not we
>> create a Vector class (whose sole purpose is to indicate that its values
>> which are identical in nature to the Point class are to be considered as
>> magnitudes).
>
> If you use homogeneous coordinates notation, than an array of doubles
> representing the vector will tell you that in fact it is a vector cause the
> last value will be 0 (in contrast to a point which is 1).

The array of doubles is probably not going to contain the last number, 
that would unnecessarily enlarge the arrays (which are there for 
performance reasons). But as Martin suggested, we may not need to handle 
vectors as arrays of doubles. Also the difference in the not-stored last 
number brings one more reason for having the classes separate - imagine 
for instance a toArray() method that wouldn't know what to place there.

>
>
>> We can either encapsulate this information in a new class and add lots
>> of methods for that new class,

We would add transform(Vector) that would otherwise exist as 
deltaTransform(Point). What other lots of methods would we need?

>> or we can encapsulate the information on
>> the naming and documentation of new methods which use old types - both
>> have equal expense in terms of method counts...

Yes, the same method counts. But for the Point-only solution we would 
need more method names, more complicated documentation, and most 
importantly, methods that seem to make no sense (as length on a point).

Thanks,
Pavel

>>                          ...jim
>
> Thanks, best regards,
>