LocalToScene Transformation (related to Affine Transforms)

[Pavel Safrata]

Hello,
I would provide some common algebra methods as "getInverseTransform()" 
or "getContatenation(Transform)" on the Transform class that would 
return a new transformation, and methods as "inverse()" or 
"concatenate(Transform)" on the Affine class, that would modify it in 
place. For the most common use-cases you should be fine with the 
specific transformations, for some more complex cases there will be an 
easy way to convert any of them to Affine (for instance 
Affine.setTransformation(Transform)) and perform the computation there. 
Does that sound good?
Thanks,
Pavel

On 14.5.2012 14:12, Dr. Michael Paus wrote:
> Hi,
> could you please explain how this will fit into the current class 
> hierarchy for transforms?
> The general Transform class has all the static methods to create 
> specific transforms. If
> the Affine class will have all the matrix algebra, then how is this 
> supposed to work?
> All the specific transformation classes Translate, Rotate, ... are not 
> derived
> from Affine and thus will not inherit the matrix algebra methods.
> Michael
>
>
> Am 14.05.2012 13:49, schrieb Pavel Safrata:
>> Hi Alexander,
>>
>> On 14.5.2012 11:21, Alexander Kouznetsov wrote:
>>> Hi Pavel,
>>>
>>> On 11.05.2012 13:33, Pavel Safrata wrote:
>>>>>
>>>>> Can't we just make Affine3D public instead? That way we'll provide 
>>>>> matrices calculation layer and all we need is to provide methods 
>>>>> to convert Affine3D to Affine and vice versa. Just an idea.
>>>>
>>>> This sounds like a bad idea to me. From user's point of view, 
>>>> Affine3D and Affine would be duplicates except that Affine's 
>>>> members are observable. What I think we should do is to port some 
>>>> of the Affine3D functionality to the Affine class (which sounds 
>>>> close to RT-17942).
>>> I don't see a really big difference here. Newly added class 
>>> regardless of its name would be "a duplicate" of Affine class. 
>>
>> I'm not going to add any new class (except of an internal immutable 
>> implementation of Transform). The Affine class is already part of 
>> public API for a long time, so we should use it and not create any 
>> duplicates of it.
>>
>>> Moreover if you're not going to port all of its methods there would 
>>> always be a feature requests to port the rest of them. 
>>
>> We will consider all the feature requests and implement the 
>> reasonable ones. If we end up with something very close to Affine3D, 
>> we may then consider switching to the public classes internally.
>>
>>> On the other hand the Affine class wouldn't be just a class that 
>>> members are observable but would be also a class that has no matrix 
>>> algebra methods and that is part of Transforms API. Affine3D is 
>>> clearly a different layer then.
>>
>> The Affine class will have the matrix algebra methods. I don't think 
>> we should publish any other layer (our proposal tries to avoid that) 
>> - that would lead to more confusion and more work with converting 
>> matrices between the layers. Everything should work with the existing 
>> classes from the user's point of view.
>>
>> Thanks,
>> Pavel
>>
>>>
>>> Best regards,
>>> Alexander Kouznetsov
>>>
>>>
>
>