Transform point using localToSceneTransform
pavel.safrata at oracle.com
Wed Jul 25 23:20:32 PDT 2012
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
> 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, best regards,
More information about the openjfx-dev