You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why are you mixing them ?
The good design, I think, should be to provide the user a function that transforms euler to quat...but then, inside the functions, always use quat...
The text was updated successfully, but these errors were encountered:
In python the situation is a bit different as we cannot override function signature and this is not a typed language. In recent STLIB component the design seems to be the following:
defaFunction(rotation):
qrotation=getRotationFromParameter(rotation)
...
with:
defgetRotationFromParameter(rotation):
iflen(rotation) ==3: # This is euler angle in degreereturnQuaternion::createFromEulerAngle(rotation)
iflen(rotation) ==4: # This is a quaternionreturnrotationraiseException("This is not a valid rotation")
Eulalie was pointing that handling degree vs radian is a mess. Degree are not SI but everything in Sofa is un Degree. So what to do ?
On my side I like approaches like these: https://pypi.org/project/numericalunits/
But this may be overkill.
There is a problem in the new implementation of getOrientedBoxFromTransorm, it creates a bug on step3 of the TRIPOD tutorial
67c1d51#r32599793
@damienmarchal could you have a look at it ?
euler Rotation is a vec3
rotation is a quat
Why are you mixing them ?
The good design, I think, should be to provide the user a function that transforms euler to quat...but then, inside the functions, always use quat...
The text was updated successfully, but these errors were encountered: