Re: [eigen] geometry module

[Daniel Stonier <d.stonier@xxxxxxxxx>]

Thanks for the great summary Benoit. Again, I'll do some more tests
tomorrow and decide on where we need to head, need to work out just
where we will be doing most of our calculations and how slow trig
lookups are compared to matrix products on our embedded boards. At
some point in the future, I might look at the quaternion case too -
has anyone else started or considered moving on that one?

> 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.

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