When editing IPO curves that are in degrees (RotX,RotY,RotZ),

the corresponding Vertex Y transform property seems to be

divided by 10. For example, insert a vertex in a curve for RotZ, and

then press “N” in the IPO window to see the properties. The

reading for “Vertex Y” is divided by 10. I would expect to see

it match the value on the Y axis display. I looked everywhere

for information on this, but couldn’t find an answer.

Yes several of the ipo types y axis are scaled by 10. I believe this was done so that if several ipo’s are displayed at the same time you can easily see the shape of all the curves without having to zoom in.

GreyBeard

I may not have explained the problem as clearly as

I could have. The problem is not in zooming/unzooming,

or anything having to do with the IPO display or its

axes or axis labels. My display correctly shows a line

going from 1 to some number of frames on the X-axis

and 0 to 360 on the Y-axis (since I wanted to rotate

around Z 360 degrees).

The problem is that the display inside the Numbers

Window (press “N”) is wrong for the Y value of any

selected vertex in edit mode. This value needs to

be multiplied by 10 to correspond to the IPO curve

that I drew. It would be a very easy fix, I would hope.

Let me know if the above better explains the problem. It

would appear to be a bug.

-paul

Yes they are scaled by a factor of ten – the labelling of the y axis is adjusted automatically for you only if a rotation ipo is hightlighted but the number stored in the ipo curve is actually degrees/10 which is why when you enter the value using the n-key you must enter degrees/10.

GreyBeard

OK, I see the effect and method, but wouldn’t it be more

logical to just use radians (as is done in the Python

access to Rot variables)? That way, all the numbers on

axes and in the numbers window would match, and

the zoom’ing issue would go way. Thoughts?

If I wanted to animate one full revolution 36 is easier to enter into the n-key dialog box than 2*pi, besides many of the artistic types have no clue what a radian is but they do understand degrees.

GreyBeard

Perhaps we can agree to disagree on this. I don’t think

that having an implicit rule like “the real number of degrees

is divided by 10 and is not what you think it is” is logical.

I think it is completely illogical. It would be much clearer

and better to have axes (on the IPO display) and

numbers (in the Number window) be correct. Having

them differ simply serves to confuse the average user

(my 2 cents…maybe others disagree). Everyone knows

what a radian is from middle school (or should).

You give the American school system too much credit I found it confusing as well, I wish the y-axis showed the actual values (I would personally perfer degrees). I just gave my opinion as to why I thought the coders did as they did.

GreyBeard

Greybeard:

You are right — the idea makes a certain kind of sense based

on the issue of trying to avoid the need to zoom the display. I

guess I just wish that we could have our cake and eat it too

with regard to getting the right values in the Numbers window,

but then also being able to easily browse IPO curves without

excessive zooming. I am going to check around to see what other

programs do (Max,Maya, etc), to see if there is a solution. These

progrems also support keyframes, and the same issue should arise

there as well.

On the side, your videos are excellent!! In fact, I watched your

complete animation video prior to posting, and have recommended

it to my students.

I don’t understand… =/

I’ve seen in Blender Python API Reference the same as you have afirmed: the values in IPO Curves are degrees/10.

But converting them as Quaternions, I’ve got some reasonable values… They are like sin[angle/2] (radians)… 0_o?

Comments please!

I’ve seen in Blender Python API Reference the same as you have afirmed: the values in IPO Curves are degrees/10.

ok

But converting them as Quaternions, I’ve got some reasonable values… They are like sin[angle/2] (radians)… 0_o?

I don’t filly understand your question. Converting what as quaternions – the actual degrees, the degrees/10 or the value in radians of degrees/10?

Here is the C code I use for converting an axis angle to quaterion.

void Quat_from_axis_angle(const Vec3d axis, const float deg_ang, Quat q)

{

float rad_angle; /* half the angle in radians */

float sin_angle;

Vec3d a;

Vec3d_copy(axis, a);

Vec3d_normalize(a);

rad_angle = deg_ang * M_PI / 360.0;

sin_angle = sin(rad_angle);

q[3] = cos(rad_angle);

q[0] = sin_angle * a[0];

q[1] = sin_angle * a[1];

q[2] = sin_angle * a[2];

Quat_normalize(q);

}

So if I was rotating 65 degrees about the x axis then the inputs are:

axis = [1, 0, 0] is the X axis

deg_ang = 65

I’ll let you do the arithmetic. How are they reasonable?

GreyBeard