I've read Eigen geometry(Quaternion&AngleAxis) documentation.
I actually used it for creating my own semi-generic Euler class. Implementation is very simple as you might think, not template-styled nor optimized.

I realized that it would be great if Eigen Geometry module will include full generic, template Euler class.

And I know I can use:
* AngleAxis - But it's one way, and it isn't a container for 3 angles.
* eulerAngles() - http://eigen.tuxfamily.org/dox/group__Geometry__Module.html#gad118fececd448d7485ffea4858775e5a - But it's not generic, and again, no container.

And yes, I know the objections:
* 48 ways to do this - http://stackoverflow.com/a/21418853/2968864
* Mathematically hard, in-trivial and very slow
* (Possible) more template meta-programming for a fast generic euler system

But here are the advantages:
* Human readability
* Standard way to represent an object rotation (e.g. simulation network protocols, I'm from this field)
* FPS player camera style
* And finally, it reduces bunch of code from the user

The technical idea is obvious, but very hard, meta programming rotation calculators, at least for the non-dynamic Euler.

I couldn't find any old proposal, but I'm sure you've thought about this. I hope I post this in the right place.

Will "Euler" class ever be in Eigne, is it planned? Good idea(at least in unsupported modules) or not?

There were an attempt before we even released Eigen 2.0: https://bitbucket.org/eigen/eigen/src/4 ... s.h?at=2.0
It was limited to one convention.

We abandoned it because of all the objections you mentioned. It turned out to be simpler to let the user use AngleAxis... All in all, why not trying to resurrect it in unsupported as a start. I would prefer not to bother about ultimate performance, and rather favor code simplicity. It could be written on top of eulerAngles() and AngleAxis<> for the conversions.

ggael wrote:There were an attempt before we even released Eigen 2.0: https://bitbucket.org/eigen/eigen/src/4 ... s.h?at=2.0
It was limited to one convention.

We abandoned it because of all the objections you mentioned. It turned out to be simpler to let the user use AngleAxis... All in all, why not trying to resurrect it in unsupported as a start. I would prefer not to bother about ultimate performance, and rather favor code simplicity. It could be written on top of eulerAngles() and AngleAxis<> for the conversions.

Thanks for the response and the expression of interest.

I think I would try to work on something generic but simple like you said, and may post it here someday.

I think I got a solution how to mix it with AngleAxis<> API:

(notice: The API naming conventions isn't critical for this post)

Introduce a new template function - AngleAxisS(placeHolderExpression):
This function takes a template type "placeHolderExpression" and return a template type(type isn't available to the user) of an AngleAxisS expression.

This expression support the (a * b) operator in this, when each parameter must be either a normal RotationBase<> expression, or an AngleAxisS expression,

I might sound complicated. Here is an example of such expression:

Code: Select all

double heading, pitch, roll;
AngleAxisS(placeHolderUser(heading), Vector3f::UnitZ())
  * AngleAxisS(placeHolderUser(pitch), Vector3f::UnitY())
  * AngleAxisS(placeHolderUser(roll), Vector3f::UnitX())


while heading, pitch and roll are real scalar variables(output variables - non const).
What the user can do with it?

She might use this expression to compute reverse euler problems(getting (h, p, r) from orientation)

Code: Select all

double heading, pitch, roll;
( AngleAxisS(placeHolderUser(heading), Vector3f::UnitZ())
  * AngleAxisS(placeHolderUser(pitch), Vector3f::UnitY())
  * AngleAxisS(placeHolderUser(roll), Vector3f::UnitX()) ).fromOrientation(/* some RotationBase<> */)
// Now heading, pitch, roll are evaluated


The user can say he want the half angle:

Code: Select all

double heading, pitch, roll;
( AngleAxisS(2 * placeHolderUser(heading), Vector3f::UnitZ())
  * AngleAxisS(2 * placeHolderUser(pitch), Vector3f::UnitY())
  * AngleAxisS(2 * placeHolderUser(roll), Vector3f::UnitX()) ).fromTwoVectors(v1Before, v1After, v2Before, v2After)// A side note: If the dot product of v1 and v2, and the magnitude of each isn't the same after, the parameters are invalid
// Now heading, pitch, roll are evaluated as the half angle


How the user choose the which operation is first? Which axis? Tait-Bryan or classic? Extrinsic or intrinsic?
By this expression!

It has a true potential. It solves ANY gimbal system. No
The question is whether this is elegant to Eigen standards. I tried that it will.

It doesn't mean that Eigen shell develop a whole global generic equation solver for all types (even that it would be cool), but to support this feature only for angle axises.

You know math better than me - but the solving implementation strategy is simple - the angle between vector and a plane, and the projection of this vector on this plane.

The idea of an Euler class still remains - It might use this kind of expression for dynamic system, but it might be a good idea to implement this feature first (if accepted).

What do you think?

This is an interesting idea, but this sounds rather overkill. I also don't understand why fromTwoVectors takes 4 vectors.

ggael wrote:This is an interesting idea, but this sounds rather overkill. I also don't understand why fromTwoVectors takes 4 vectors.

Thanks for your response.

A after = A before * rot
B after = B before * rot

Solve this to get rot, just a common use case from my experience. It was simpler if I could take only one vector pairs instead of two, but it isn't matched to only one rotation.

And about the overkill: you can simplify this to functions: AngleAxisHeadingd(axis) and so for pitch and roll if this looks simpler. Also you can have a one and only one fixed type for this expression if this make it simpler.

You can use three template parameters of [+/-][h/p/r] to the function instead, but this doesn't solve the generic gimbal system, which isn't so bad, but isn't simpler to use either.

What do you think that is more preferred?

I'd rather stick with a simpler EulerAngles class. See also the following bug entry for needs to allow to customize the angle ranges when converting rotation to Euler angles: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=947