Affine transforms - matrix algebra

[Jim Graham]

Also, what about inverseTransform(point/bounds) methods?  And 
deltaTransform()?

			...jim

On 7/23/2012 2:11 AM, Pavel Safrata wrote:
> Hello,
> looks like we reached the agreement on a (well documented)
> append/prepend terminology with the original proposal semantics reversed.
>
> Before I post the final proposal, following changes need to be discussed:
>
> We need to add manual transformation methods to Transfrom class. This is
> very important, I can't believe I've forgotten them..
> public Point3D transform(Point3D point)
> public Bounds transform(Bounds bounds)
> Any other?
>
> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3,
> MAT_3D_3x4, MAT_3D_4x4, do you agree?
>
> Keep the methods accepting arrays recognizing their types according to
> their length and add
> public Affine(double[] array, MatrixArrayType type, int beginIndex)
> public void setToTransform(double[] array, MatrixArrayType type, int
> beginIndex)
> public void append(double[] array, MatrixArrayType type, int beginIndex)
> public void prepend(double[] array, MatrixArrayType type, int beginIndex)
> Do you agree? Or would you prefer different set of array-accepting methods?
>
> Regarding the getRow/getColumn: we again face the problem whether to
> return 3 or 4 elements. Consistently with the toArray, I propose
> VectorArrayType = { VAT_2D, VAT_3D }
> public double[] getRow(int row, VectorArrayType type),
> public double[] getRow(int row, VectorArrayType type, double[] array)
> public double[] getColumn(int col, VectorArrayType type),
> public double[] getColumn(int col, VectorArrayType type, double[] array)
> Do you agree?
>
> Thanks,
> Pavel
>
> On 21.7.2012 2:52, Martin Desruisseaux wrote:
>> Hello Jim
>>
>> No worry, I don't think that anyone felt sent off. I think that
>> peoples know that emails can give all kind of impression not always
>> accurate.
>>
>> I wasn't aware that a concept of transformation chains could be
>> associated to nodes. Given that this chain is in reverse order
>> compared to the one I was familiar with, I understand the difference
>> in interpretation of "append". I agree that consistency is important.
>> I have no problem with any choice, but I would just like the
>> explanation about transformation chains (in the JavaFX sense) to
>> appear somewhere in the javadoc, for helping some developers
>> (including myself) to do the right association in their mind.
>>
>> Thanks and regards,
>>
>> Martin
>>
>>
>>
>> Le 21/07/12 02:02, Jim Graham a écrit :
>>> When I wrote my first reply in this thread I tried to warn people
>>> that I was coming back from vacation to a long thread and I hadn't
>>> double checked all of the math that was being proposed, so I was
>>> commenting from a general perspective that wasn't necessarily in
>>> agreement or conflict with the current proposal at the time. I hope
>>> that I didn't send people off on a wild goose chase based on my list
>>> of points that may have come from a negative "we shouldn't do this or
>>> that" kind of perspective.
>>>
>>> To switch things around, let me make some positive statements of
>>> something that I would find acceptable and which I think may have
>>> actually been formally proposed here (but I didn't "do the math" to
>>> verify that).
>>>
>>> I believe that the following produce equivalent transforms:
>>>
>>> --------------
>>> Node.getTransforms().add(new Scale(sx,sy));
>>> Node.getTransforms().add(new Translate(tx,ty));
>>> ---
>>> t = new java.awt.geom.AffineTransform();
>>> t.scale(sx, sy);
>>> t.translate(tx, ty);
>>> ---
>>> t = new java.awt.geom.AffineTransform();
>>> tmp = new java.awt.geom.AffineTransform();
>>> tmp.setToScale(sx, sy);
>>> t.concatenate(tmp);
>>> tmp.setToTranslate(tx, ty);
>>> t.concatenate(tmp);
>>> ---
>>> Node n...;
>>> Group g = new Group(n);
>>> g.setScale(sx, sy);
>>> n.setTranslate(tx, ty);
>>> --------------
>>>
>>> We also have the fact that "preConcatenate()" is mathematically
>>> reversed, and also inside-out from the perspective of what is being
>>> manipluated, as compared to concatenate().
>>>
>>> So, if "appendFoo(...)" was essentially equivalent to:
>>>
>>> - Node.getTransforms().add(new Foo(...));
>>> - t.foo(...);
>>> - t.concatenate(tmp.setToFoo(...));
>>>
>>> and "prependFoo(...)" was essentially equivalent to:
>>>
>>> - Node.getTransforms().add(0, new Foo(...));
>>> - we don't have a Java2D reverse for t.foo();
>>> - t.preConcatenate(tmp.setToFoo(...));
>>>
>>> then I could be happy. It may not have complete unambiguity in an
>>> absolute sense, but it would at least establish an internal
>>> consistency and harmony of naming conventions with respect to the
>>> JavaFX Node transform attributes and with the prior art in the Java
>>> geometry family (AffineTransform)...
>>>
>>> I feel that append, while we can argue the semantics of what it might
>>> mean mathematically, sounds like the more natural verb of the two
>>> forms of methods (comparing appendFoo to prependFoo), and in general
>>> it is the set of methods that they probably want to be using if they
>>> come from Java2D, or if they are writing code that takes a transform
>>> from somewhere else that defines their "transformation context" and
>>> they want to work within that (if you prepend, then you override the
>>> context someone set up for you, if you append, then you take their
>>> context and work relative to it).
>>>
>>> Is that what was being proposed before I came in and stomped on the
>>> discussion?
>>>
>>> ...jim
>>>
>>
>
>