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