[Bf-python] Mathutils::Euler and Math in the API-doc

[Joseph Gilbert]

Yea i saw that before too. I don't like the format some data is returned in.
I personally think degrees are easier to work with than radians, which is
why Euler uses degrees. I was planning on fixing the radians format
elsewhere eventually. This is a preference but a 3D euler with radian values
is not usually expected.

You're observant with regard to the spaces' of the matrices. All data (i
believe) is localspace - meaning that it is always in the coordinate system
of it's parent (localspace). For most objects this isn't a problem because
they aren't parented and so their localspace = worldspace (the coordinate
system of blender). This is a reflection of how children are transformed
when the parent object moves. This is mostly a problem with Bone/Armature
because almost all bones are parented, however it also applies elsewhere (ie
objects). Setting a 'worldspace' matrix for Bones would be a great help but
It's also complex on the math (decomposing a matrix into localspace
axis/angle) and Ive left it alone for now (especially when you involve IK
parenting and constraints - yikes!).

The other thing about these data types is that most of what python does is
'expose' the C variables to the world. This doesn't always result and
practical and useful things. When the bone module was written, it exposed
quat, loc, size, etc. however, some of these variables are useful in posing
others are useful in changing the rest pose only. This is something that
needs some housecleaning.

-----Original Message-----
From: bf-python-admin at blender.org [mailto:bf-python-admin at blender.org]On
Behalf Of Anders Nilsson
Sent: Monday, June 07, 2004 7:06 PM
To: bf-python at blender.org
Subject: [Bf-python] Mathutils::Euler and Math in the API-doc


1) First I'd like to point out a problem with euler objects in
blender-python.

* Mathutil.Euler rotations are specified in degrees
* Objects rotation - obtained using getEuler() - is specified in radians
* IPO-tracks for rotation specifies euler angles as decadegrees (90
degrees=9 decadegrees)

This seems somewhat inconsistent to me. I know that the last thing is
due to historical reasons with the IPO-editor. The other two might be
natural given that Mathutil.Euler must be chosen such that it makes
sense for scripting and object.getEuler() can't be change or much code
would be broken. Still I see it as a problem.

2) Another thing is that almost none of the matrices provided in the API
are documented (what space? do they want post- och pre-multplication
with row or column-vectors?). What's up and what right, what coordinate
system are we in etc. Same goes for quats and especially the armatures.
I usually play around some until it works (tm) but that seems a bit
tricky.

What spaces what are defined in as well as armatures is the same for
python as it is for blender internal so perhaps some documentation that
is common to both? Perhaps it exists? Please enlighten me :)

Anders Nilsson (breakin)

_______________________________________________
Bf-python mailing list
Bf-python at blender.org
http://www.blender.org/mailman/listinfo/bf-python