LocalToScene Transformation (related to Affine Transforms)

[Pavel Safrata]

Hello Martin,
your comments make perfect sense. However, I seriously doubt our scene 
graph would ever be able to operate with such general transformations. 
Apart from the fact that we would most probably have a great trouble to 
implement all the existing functionality if such transformations were 
allowed, it would bring a serious performance drop and would create an 
API considerably less handy for the usual cases. Anyway, if we decide 
that the naming issue is serious and/or that we want to leave the door 
open to the generic transforms, we can do following: insert a new class 
(say AffineBase) as a subclass of Transform and superclass of all the 
existing transforms, then go with our proposed solution using AffineBase 
instead of Transform. To me it seems as a good thing to do.
Thanks,
Pavel

On 10.5.2012 17:30, Martin Desruisseaux wrote:
> Hello all
>
> Le 09/05/12 17:16, Pavel Safrata a écrit :
>> We considered another option: creating a new class 
>> TransformationMatrix. This class would be immutable and would contain 
>> various methods for work with matrices. All the transforms would have 
>> a getter that would return an instance of this class, the Affine 
>> class would have also a setter. Now the localToSceneTransformation 
>> property could be of type TransformationMatrix. This would spare us 
>> the above problems and provide an independent class for matrix 
>> operations, but on the other hand, converting transformations to the 
>> matrix and back may be an unnecessary burden, also doing some complex 
>> matrix computation with an immutable matrix class would result in 
>> pretty huge garbage production (slowing down the computation).
>
> If this approach was selected, maybe a plain "Matrix" class name, with 
> 'getNumRows()', 'getNumColumns()' and 'get(i,j)' methods would be 
> sufficient. This would allow usage in two-dimensional cases (as 3×3 
> matrices), three-dimensional cases (as 4×4 matrices), perspective 
> transform (which is not affine, but still represented by 3×3 matrices) 
> or other matrix operations not necessarily related to coordinate 
> transformations.
>
> For example, when dealing with generic (not necessarily affine) 
> coordinate transformations - for example map projections -, 
> transforming a point is not always sufficient. Some time we need the 
> mathematical derivative of the transform at a given point. In the 
> particular case of affine transforms, the derivative is trivially the 
> same everywhere, which may explain why Java2D has never feel a need 
> for it (note however that java.awt.geom.AffineTransform has something 
> close: the deltaTransform(...) method). But in the general case the 
> transform derivative may vary at any point, and the result of a 
> transform derivative can be express as a matrix. See for example:
>
>     
> http://www.geoapi.org/snapshot/javadoc/org/opengis/referencing/operation/MathTransform.html#derivative%28org.opengis.geometry.DirectPosition%29
>
> The derivatives are useful for example because a map projection may 
> change straight lines into curved lines, and the derivative are useful 
> for computing Bézier curves that approximate those curves. They are 
> also useful for helping some iterative algorithms to converge faster. 
> If the matrix class name was "TransformMatrix", we would need a 
> "DerivativeMatrix" for the above case, and likewise for all other 
> matrix usage. I think that a plain "Matrix" class of arbitrary 
> dimension would fit better the need.
>
>
>> So we propose yet another approach. In the base Transform class, 
>> introduce getters for all the elements of the transformation matrix 
>> (not observable, just getters). Each transformation would be able to 
>> return the values according to its current state. Our property would 
>> then be of type Transform, allowing only for getting the matrix 
>> values. This would make the property observable as a whole (creating 
>> a new instance each time), unmodifiable, and would leave us with a 
>> nicely open way to introduce the methods for matrix operations on the 
>> Transform class, most of them probably returning the Affine instance 
>> as a result, and the Affine class could then have a bunch of methods 
>> to be modified in place.
>
> If this approach was selected, the "Transform" class name would become 
> unfortunate, because the class name suggests arbitrary transform, 
> while the above-cited getters would in practice restrict the transform 
> to the affine case. This would be yet more confusing since an Affine 
> class already exist. If we were allowed to rename the classes, it 
> seems to me that the "Transform" class would need to be renamed 
> "Affine" (because "Translate", "Scale", "Shear" and "Rotate" are 
> special cases of affine transforms) and the current "Affine" would 
> have to be renamed into something else, maybe "GeneralAffine".
>
> I would like to propose a mix of those two approaches: the 
> 'localToSceneTransformation' property would be of kind "Transform" 
> like the second proposal, but instead of individual getter methods for 
> various matrix coefficients, provide the following method in the 
> Transform class:
>
>     public abstract Matrix getMatrix(Point3D location);
>
> For every current JavaFX implementations, the Point3D argument would 
> be ignored and can be null. For custom implementations, e.g. map 
> projections (or anything which is non-linear), the result vary for 
> each points. This method would copy the current Transform state in a 
> new Matrix object (i.e. take a snapshot) - so no need for new 
> Transform instance when the state change, and no need for new Matrix 
> instance when performing matrix operations (the operations could be 
> applied in-place in the existing Matrix instance).
>
>     Martin
>