xyz inconsistency? mesh versus window

Hmmm, I’ve just animated a bouncing ball using IPOs from scratch. This is the traditional stretch, squash, pause, stretch, slow, fast animation found in many animation lessons.

It seems that the LocZ IPO controls vertical location but SizeY controls vertical deformation in the mesh. How come one vertical measurement system is Z and the other Y ?

The UV sphere was placed in top view (NUM7) - does this mean its local co-ords are out of sync with the global co-ords?



If you go into the object buttons (F7) and click the Axis button, you will be able to see the local axis of the selected object in the 3D window. That should make it easier when dealing with local stuff.


Ahh, that’s the button I was looking for (in the wrong place). Unfortunately it shows that the sphere’s Z axis is indeed vertical, the same as the global co-ords. However, the SizeY IPO is doing the vertical squashing and the SizeZ applies the “widening”.

Hang on, just realised. I’m using a Lattice for the deformation and the Lattice was added in front view (Num1) - and therein lies the answer to my question. :slight_smile: Thanks for the axis tip (I was looking in mesh tools).

Even odder perhaps: if I start with a fresh screen and the default cube then apply a ROT keyframe at frame 1, then move forward a number of frames, and rotate the cube 180% constrained along the Y Axis, the playback still rotates in all 3 dimensions so two IPOs have to be deleted.

I know that simple keyframing is known to cause such problems but I assumed that using a constraint (RKEY, YKEY) would limit the automatic IPO to just the rotY channel and that the worst that might happen is that it would rotate the wrong way from startframe to endframe.

2.37a (Max OSX)

When you insert keyframes via I, it adds all 3 axis and you need to go in and delete them. Its not too bad.

The thing is, and I still don’t fully understand this, that Blender seems to use two axis systems. One is like normal life: X = left, right; Y = forward, back; Z = up, down. But the other is like the graphs you use in geometry where Y is the up/down and Z is the forward back.


The problem is that when you rotate an object it doesn’t change the RotX/Y/Z directly. It goes via a rotation matrix or quaternions or something like that (I don’t know for sure, but I’d guess at a rotation matrix). This means if there’s two ways to describe the rotation as Rot X/Y/Z, it could be represented as either.

For example, a rotation of (0, 180, 0) and a rotation of (180, 0, 180) are the same orientation, so either may come out the other end of the operation. Similarly, if you rotate by 360 degrees, then the Rot X/Y/Z values won’t change.
Using eg R,Y to constrain the rotation only constrains the interface, not the code in the background.

If you want to force it you have a few options:

  • Make the IPOs by hand. Not too hard if they’re simple, but if they get too complicated it can get annoying.
  • Add a keyframe at 90 degrees and then add the final keyframe at 180 - this is enough of a hint for blender to get the rotation in the right direction.

Thanks guys. Perhaps future releases might take account of keyboard constraints and apply them to any auto IPOs.

Actually, I’ve had quite a bit of fun with the IPOs making a ball travel in x,y direction whilst bouncing, squashing stretching and rotating all at the same time. Then I used the Time IPO to make a slow-mo version of it :smiley:

I’ve learned a fair bit from this exercise.

One thing I can’t figure out is how to “compress” or “stretch” an IPO curve: ie, make its length shorter without reducing its height - so as to make the same animation take place in half the time for example (without using Time IPO). S,X certainly doesn’t seem to do it. :frowning: