BUG with rotations (?) in Python and in the transform properties panel (?)

Hello.
I think i ve stumbled apon a bug in the transform properties panel.
I ve opened a thread here
But there is more to it.
Unfortunately i can’t join a .blend file as attachment…
Just create a blank scene with a randomly rotated cube.

Rotate along X local axis (RXX):
look at the values of rotation in the Transform Properties panel…
–> Just rot X changes

Rotate along Y local axis (RYY):
look at the values of rotation in the Transform Properties panel…
Everything changes !

Same for RotZ…

This is just “cosmetics”: if you type a certain value for your local Rot Y then it is applied correctly…

BUT

Now have a look at this script:

import Blender as B
from Blender import Object
selObj=B.Object.GetSelected()
obj=selObj[0]
obj.RotX=obj.RotX+0.35
B.Redraw()

Load it into a txt window

Alt-P as many times as you want
You can see the object nicely rotating around its X axis.
In the Transform panel: only X rotates

Now change the RotX argument to RotZ (both)
Alt-P
This time, in the Transform properties panel, everything is more normal:
only RotZ changes…
BUT ! look at your cube: it isn’t rotated aroud its Z local axis anymore !
It seems to rotate around the GLOBAL Z instead

Now change the RotZ argument into RotY (both)
Alt-P
The panel shows only the Z rotation changing … OK

BUT ! (again)
It doesn't rotate around its  Y local axis
INFACT   IT EVEN DOESN'T ROTATE AROUD THE GLOBAL Y AXIS !

Someone has a clue ???

An update:
Toloban actually pointed to that same matter some time ago…

Middle of that thread…

Gwenouille,

Is this the same issue? Bug Tracker issue #5900.

https://projects.blender.org/tracker/index.php?func=detail&aid=5900&group_id=9&atid=125

Here is a similar case, issue #2944

https://projects.blender.org/tracker/index.php?func=detail&aid=2944&group_id=9&atid=125

This had to do with the “Protect” feature, it is unrelated.

Here is a similar case, issue #2944

https://projects.blender.org/tracker/index.php?func=detail&aid=2944&group_id=9&atid=125

That was a different issue altogether, related to transform constraints space switching. It is fixed anyway, when Global is selected, the second space is Local.

Martin

@OBI_Ron: as theeth said, they seem to be unrelated to the pb i point to.

@theeth: I believe it is a very serious flaw. Whom should i contact ?
Maybe the bug-tracker ?

Posted to the bug tracker.
Seems quite serious to me.
Number 7509.

Sorry to double post (ouch triple actually), but i’d like to know what happens next when a bug is reported to the bug tracker.
How long does it take until someone qualified tackles the problem?
Is there another step to take, like directly contacting one of the people listed in the “assign to”
list?
The fact is: i’have written a script which code partly relies on the functions being hampered by the bug.
Should i release a “light” version of my script and release another, complete, one once the bug is fixed ?
Or is it reasonnable just to wait for that to be corrected ?
I’d like to be able to do that myself, but i’ve just made my first steps with python and C scares the hell out of me…
Besides i have no idea where the code for that lies…

Finally had time to look at this correctly (sorry for that, last time, I only tried to reproduce quickly).

I’ll go through the first point since it kinda explains the rest (I’ll report in the tracker too).

Rotate along X local axis (RXX):
look at the values of rotation in the Transform Properties panel…
–> Just rot X changes

Rotate along Y local axis (RYY):
look at the values of rotation in the Transform Properties panel…
Everything changes !

This is normal behavior. Euler angles (what is displayed in the panel) are a set of rotation applied one after the other around GLOBAL axis (otherwise it wouldn’t have 3 degrees of freedom). The rotations are applied in the order they are displayed (X,Y,Z), so that explains why rotation around LOCAL X always changes only the RotX value and rotation around GLOBAL Z the RotZ value. RotY doesn’t correspond to either LOCAL or GLOBAL in most case.

That also explain the behavior of your script.

So, to make this clear, this is not a bug, this is normal standard behavior (not just Blender).

If you want to do rotations around arbitrary axis in Python, you’ll have to use matrices (rotation matrices can be generated automatically, you don’t have to do it by hand).

Martin

Hello Martin !
Thank you for taking the time to look at that and explain it to me !
Ok i understand a bit better the first part of the problem, the one with the transform properties display panel…

But why then does the RotZ function in the Python API make the object rotate around the GLOBAL Z axis ? and rotY around an axis i can’t recognise ?

I don’t grasp the reason for that…

this is quite frustrating: it just feel i am in front of a wall and i can’t find the door…
I think i can find a way round using matrices as you pointed: it offers another aera i can learn from !

I’d be glad to understand this rotation behaviours though…

From the same reason that doing a rotation around GLOBAL Z affects only that RotZ parameter (except in reverse).

Like I was saying:

The rotations are applied in the order they are displayed (X,Y,Z), so that explains why rotation around LOCAL X always changes only the RotX value and rotation around GLOBAL Z the RotZ value. RotY doesn’t correspond to either LOCAL or GLOBAL in most case.

Changing RotX, RotY and RotZ in Python is like typing in values in the properties panel.

RotY is not equivalent to GLOBAL nor LOCAL because it is a global axis rotation done after the rotation around global X but BEFORE the rotation around global Z, so it would be like a rotation around the global Y axis after rotating it by the Rot Z parameter.

You can test this visually in this blend file: http://blenderartists.org/~theeth/temp/axis.blend

Rot Z is 30 degree, therefore, I’ve rotated the viewport 30 degree to align VIEW Y with our rotated GLOBAL Y. So, if you rotate around VIEW Y (R Y Y), you’ll see that only the Rot Y parameter in the properties panel changes, as predicted.

I hope that helped.

Martin

Thank you Martin for all your explanations.
While i still have trouble visualising all that, i am happy to learn that all that is fully normal.

Thanks for having removed the bug report.

I waited a week or so before i decided to post it, and because there was not a lot going on in this thread, i thought i really was facing a bug.

Sorry if i spoiled your time !

Can you close or even delete this embarrasing thread ? :o

Can you close or even delete this embarrasing thread ?

Nah, we all have to learn to live with our mistakes.

%<

Besides, it can be useful for other people too, in the future.

Martin