PDA

View Full Version : My inbetween frames keep busting.



kjl
05-17-2005, 05:24 PM
Edit - the problem is different than I originally thought - the real problem is described HERE (http://vbulletin.newtek.com/showthread.php?p=273696#post273696)

----- original post below -----
Anybody seen this before? I'm sure I'm doing something dumb but I'm not too familiar with LW.

I made a simple jointed object (a hand), rigged with bones.

I made a simple animation from one keyframe to another where the index finger bends using only pitch. I stepped through the inbetween frames and they were fine. Then, I animated the middle finger the same way, through only pitch controls. When I stepped through the inbetween frames again, the middle finger was fine, but the index finger veered wildly off course (the heading was busted), but came back to the correct positions at the keyframes.

I checked the dopesheet (or whatever that grid-style view is on the right half of the scene editor) and made sure I have no extra keyframes in the index finger animation. Anybody have any idea what could have possibly broken? I ripped out all the animation and tried it again, and the same thing happened.

I was animating with only rotates in local space.
The bone animation was broken as well as the geometry (not a case of geometry pulling away)
The entire hand had been rotated, so local space was not the same as world space.

Thanks!

Psycho Zo
05-17-2005, 05:46 PM
The only times I've come across this is:
1. When keyframes slip in the scene editor - which you say you checked so no dice.
2. If the weight maps are set up wrong in the model - which you counteract by saying not just the geometry was pulling away.

So seems you've explored the main possibilities. (Good work!)

Then again, if your weight maps are set up wrong then perhaps you set it so that the bone inside that particular finger reacts to the pull of other bones. Check your bones to see that you haven't set them to react to one another. Alternatively this could occur if you have been setting up IKs or parenting things and accidentally parented/IK'd them to one another.

toonafish
05-17-2005, 06:12 PM
This is probably a Gimball problem. Even when you rotate your bones in Local space, the animation is solved in parent space. So layout probably made some keyframes in the heading and banking to rotate the bone.

It's better to always use Parent coordinates when you're animating rotational values, then you can see what's going on. Layout won't solve any rotational problems when you change the coord sys to local or world, it just behaves differently while keyframing but the in-betweens won't be what you would expect.

So when you change to parent coord and the pitch is off, you might be able to fix it with Bone Twister and Align Pitch in the bone tools, recording the pivot rotation, or fixing it manualy by adjusting the banking of each parent of every bone that isn't rotated correctly.

If you need to do it manualy. Go to the rest pose, ( usualy frame 0 ) unparent the child temporary with parent in place active, rotate the banking of the parent so the little blue arrow points in the direction where you want the Pitch of the child to go. Rest the parent, and re-parent the child with parent in place active.

kjl
05-17-2005, 07:10 PM
This is probably a Gimball problem. Even when you rotate your bones in Local space, the animation is solved in parent space. So layout probably made some keyframes in the heading and banking to rotate the bone.

Yeah, I had a fear that it might be this... and I remain hopeful that it isn't :) If this was the problem it should not have played back correctly the first time (after I placed the index finger keyframes but before I placed the middle finger keyframes), correct? Also, if I look at the numerical values of H,B,and P when I rotate the finger with the green ring, only P is changing (it's not dumping lots of values in H and B), so I would assume that whatever space that I'm in is its preferred rotational space.


It's better to always use Parent coordinates when you're animating rotational values, then you can see what's going on. Layout won't solve any rotational problems when you change the coord sys to local or world, it just behaves differently while keyframing but the in-betweens won't be what you would expect.

Hmm - how do people rig things in LW so that they can rotate bones cleanly around an axis that is not lined up with the parent's coordinate system? Say a hinge tilted at 45 degrees from the wall? Do they put a dummy bone angled at 45 degrees to establish the coordinate system and then attach the real bone to that? I sort of figured one of the only reasons to use a bone (especially with rigid objects like hinges) would be to define what coordinate space you wish your translates and rotates to occur in

Thanks for the help! I know these are noob questions.

kjl
05-17-2005, 11:32 PM
Interesting: I dug a little deeper and figured out my problem exactly.

It is really easy to reproduce:

Start up layout.
Add a null.
Enter rotate mode (y)
lock H and B (click on the H and B buttons in the lower left)
Rotate null and try to make it rotate to (0,100,0)


What happens is that you can rotate all the way up to (0,90,0), and then at 90 degrees it flips over, and instead of 100 degrees, you end up with (180,80,180).

(180H,80P,180B) does indeed = 100 pitch, so the keyframe will look correct, but of course having (180,80,180) instead of (0,100,0) will totally screw up the inbetweens if your first keyframe looks something like (0,45,0).


If I manually enter in (0,100,0) at keyframe 2, everything works fine, so the local/world/parent space isn't a problem at all - as long as the keyframes are set right all the inbetweening works right.

So, I guess my new question is: is there a way to tell LW not to mess with H and B and solve for just P? I've already locked the H and B channels by clicking on their respective buttons in the lower left, so when I rotate the bone, only P changes (until I hit 90 degrees, at which point everything flips over). (this happens in world, parent, and local coord spaces)

Thanks again,

toonafish
05-18-2005, 11:46 AM
Yeah, I had a fear that it might be this... and I remain hopeful that it isn't :) If this was the problem it should not have played back correctly the first time (after I placed the index finger keyframes but before I placed the middle finger keyframes), correct? Also, if I look at the numerical values of H,B,and P when I rotate the finger with the green ring, only P is changing (it's not dumping lots of values in H and B), so I would assume that whatever space that I'm in is its preferred rotational space.


That's true, maybe you can post some screenshots to give us a better idea of what's going on.




Hmm - how do people rig things in LW so that they can rotate bones cleanly around an axis that is not lined up with the parent's coordinate system? Say a hinge tilted at 45 degrees from the wall? Do they put a dummy bone angled at 45 degrees to establish the coordinate system and then attach the real bone to that? I sort of figured one of the only reasons to use a bone (especially with rigid objects like hinges) would be to define what coordinate space you wish your translates and rotates to occur in
.

You can use a dummy bone or record the pivot rotation which will reset all rotations to zero.




What happens is that you can rotate all the way up to (0,90,0), and then at 90 degrees it flips over, and instead of 100 degrees, you end up with (180,80,180).


Yep that's what's called "Gimall Lock". It's when the Pitch ( Y axis ) and Bank ( Z axis ) meet, and you loose one rotational axis. Unfortunately Lightwave is not very smart at resolving rotations that encounter this problem, so sometimes you end up with very unlogical rotations.





So, I guess my new question is: is there a way to tell LW not to mess with H and B and solve for just P? I've already locked the H and B channels by clicking on their respective buttons in the lower left, so when I rotate the bone, only P changes (until I hit 90 degrees, at which point everything flips over). (this happens in world, parent, and local coord spaces)

Thanks again,

You can set the rotational limits to zero in the min and max for the H + B of your bones in the motion panel > controllers and limits. Unfortunately locking channels in the small input field in the lower left corner only applies to parent rotation coord.
But if you encounter this problem, it's best to fix the it by setting the whole thing up properly. It might bite you in the *** at a later stage, and you'll lose all keyframes.

toonafish
05-18-2005, 11:49 AM
hahaha ! even A.S.S. is bleeped out.

kjl
05-18-2005, 03:43 PM
Yep that's what's called "Gimall Lock". It's when the Pitch ( Y axis ) and Bank ( Z axis ) meet, and you loose one rotational axis. Unfortunately Lightwave is not very smart at resolving rotations that encounter this problem, so sometimes you end up with very unlogical rotations.

Yeah, I am familiar with gimbal lock :( It does suck, but it seems like it should not be an issue here - I've locked down H and B, so it seems like I should be able to drag P around and expect that only P will change... But I guess what is happening is that no matter what channels you've got locked or what coord space you're in, your rotation affects the axes appropriately, and then LW takes the axes and recomputes what H, P, and B should be all over again, and that last operation will do whatever it feels like.


But if you encounter this problem, it's best to fix the it by setting the whole thing up properly.
What is "properly"? This problem with exceeding 90 degrees in Pitch occurs in global, parent, and local spaces. Do I need to prerotate all my bones so that the useful range of pitch rotation occurs between -90 and 90 degrees, instead of 0 and 180 degrees? It seems to me that it would be unintuitive to make an elbow where P=0 means your elbow is bent at 90 degrees, P=-90 means the elbow is straight, and P=90 means the elbow is fully bent. Or I could rotate the bone so that Heading controls the elbow, and not Pitch, but that is also gross.

Heh, yeah that language filter is funny - I was trying to get some lscript help earlier and ctlmeshiitems() kept on getting filtered out... if I left off the second 'i' ;)


Thanks again,