LocalToScene Transformation (related to Affine Transforms)

[Dr. Michael Paus]

Not really.
If the Affine class is the only one on which you can perform matrix 
algebra then I would
like to be able to work with only this class right from the beginning 
and not having to
convert other classes to Affine just in order to be able to perform some 
math on them.
I just find this all very confusing and inefficient. But maybe others 
have an opinion on
this too.
Michael

Am 14.05.2012 15:21, schrieb 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
>>>>
>>>>
>>
>>


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.