Re: [eigen] geometry module

[Rohit Garg <rpg.314@xxxxxxxxx>]

> I think Rohit started work on dual quaternions, but don't know the
> status of that.

It's finished as in it's working all right. But it needs to be
eigen-ified before it can be merged. And I am afraid that bit is
stalled. :(
>
>>
>>> as said above:
>>>  - for 3d isometries, quat+vector or quat+quat have been discussed
>>> previously, would be a welcome addition
>>>  - for 2d isometries, angle is inefficient, combining
>>> Rotation2D+vector is the right approach.
>>
>> Isn't Rotation2D just a wrapper around an angle though? In which case
>> I think you mean the transform classes or simply a 2x2 matrix + 2x1
>> vector.
>
> You're right, I didn't realize it, but Rotation2D is indeed a wrapper
> around an angle.
>
> So that makes me think that I'm not sure how much I like the name
> Rotation2D for that. How about Angle2D instead? Would be consistent
> with AngleAxis.
>
> Benoit
>
>>
>> On 7 September 2010 19:57, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> 2010/9/7 Daniel Stonier <d.stonier@xxxxxxxxx>:
>>>> As I mentioned in the previous email, I've been having a gander at the
>>>> new geometry module. Not sure who's putting it together, but wondering
>>>> if they'd mind me picking their brain a bit.
>>>>
>>>
>>>
>>> First of all, the Transform class is for transformations represented
>>> by matrices i.e. homographies. It's not a statement that no other
>>> representation is interesting, it's just what this class is doing.
>>> Other representations may be added as separate classes.
>>>
>>>> We're using transforms for robotics, so strictly rotations and
>>>> translations. A 2D setup might only need 3 variables, angle + x-trans
>>>> + y-trans.
>>>
>>> The problem with representing a transformation using an angle, is that
>>> subsequent computations are relatively slow as one needs to compute
>>> cosines and sines. If however you're OK with representing the angle as
>>> a (cosine, sine) pair, then Rotation2D is doing that. If you want a
>>> class that combines a Rotation2D with a translation vector, which
>>> could be called Isometry2D, indeed we don't currently have that.
>>>
>>>> A 3D setup could most efficiently run with quaternion + 3
>>>> element vector for translation.
>>>
>>> Here, "most efficiently" depends on what you're doing. If you want to
>>> apply this transformation to a vector, it's going to be faster if you
>>> have a matrix representation of your transform, as the Transform class
>>> does. This is one of the most performance-critical use cases...
>>>
>>> That said, either what you propose (quaternion+vector) or a "dual
>>> quaternion" class as has been discussed previously on this list, would
>>> be interesting. We just happen not to have that yet.
>>>
>>> I think that given sufficiently explicit names, different classes can
>>> coexist. The name Transform may not be very explicit though, but the
>>> matrix approach is the only one to be generally applicable (any size,
>>> no assumption on the transformation...) so that warrants a relatively
>>> generic name.
>>>
>>>> I see that some optimisations are
>>>> being made to the transform class - e.g. CompactAffine. There is also
>>>> Isometry - how exactly does this differ from the Affine types,
>>>
>>> Isometry means Affine from the point of view of storage. The only
>>> difference is that if you use Isometry, then you guarantee that the
>>> transformation is actually an isometry, i.e. an orthogonal
>>> transformation + translation vector. This allows Eigen to generate
>>> faster code for certain operations like inverse().
>>>
>>> By the way --- others: shouldn't Isometry be CompactAffine instead of
>>> Affine? Or should there be a CompactIsometry, etc.
>>>
>>>> and
>>>> was/is there any design thoughts behind more optimised
>>>> storage/calculation processes (i.e. quaternion instead of 3d rotation
>>>> matrix, angle value instead of 2d rotation matrix)?
>>>
>>> as said above:
>>>  - for 3d isometries, quat+vector or quat+quat have been discussed
>>> previously, would be a welcome addition
>>>  - for 2d isometries, angle is inefficient, combining
>>> Rotation2D+vector is the right approach.
>>>
>>> Benoit
>>>
>>>>
>>>> Many thanks,
>>>> Daniel Stonier.
>>>>
>>>> --
>>>> Phone : +82-10-5400-3296 (010-5400-3296)
>>>> Home: http://snorriheim.dnsdojo.com/
>>>> Yujin Robot: http://www.yujinrobot.com/
>>>> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Phone : +82-10-5400-3296 (010-5400-3296)
>> Home: http://snorriheim.dnsdojo.com/
>> Yujin Robot: http://www.yujinrobot.com/
>> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
>>
>>
>>
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/