PDA

View Full Version : "Target Item" driving me nuts!


Werner
03-03-2006, 12:24 PM
Any of you out there having problems with "Target Item"? Every time I target a bone to a null, it points completely in the wrong direction. What the beeeeep is up with that? I reset my rotation values of the target item, to be the same as the bone rotation values, but it still jumps towards the wrong direction.

This is supposed to be a very straight forward tool. am I doing something wrong?

Giacomo_M
03-03-2006, 02:28 PM
I share your frustration. "Snapping" bones seem to be a huge problem in 3D, and it seems odd to me that more people don't post about it. I suspect that your problem has something to do with "gimbal lock." (For further info on this topic, I guess, you could Google "gimbal lock" and start learning :P)

Good luck.

GM

Carm3D
03-03-2006, 02:45 PM
If Gimble lock is the problem, the solution is simple.

Clone the bone you want to target. Shrink the new clone's rest length to get it out of the way and turn it's strength to 0. Now parent the targeting bone to it's little clone. This will reset it's rotation. No more gimble lock.

proton
03-03-2006, 06:07 PM
IS the bone facing down the +Z....that could be the quick fix.

Werner
03-04-2006, 10:41 AM
thanks guys!
I already found ways to work around this, but for what the "target item" tool is suppose to do, I think these problems should be sorted out. I want it to work the way it should work, no matter what direction bones are pointing. They should just target the object or null that I selected, and not point in some weird direction after I reset the rotation values. It just sounds logical to me.
Don't you guys think this is something that should be fixed? Is it worth it to drop the right people at Newtek an email about this?

Carm3D
03-04-2006, 02:17 PM
I want it to work the way it should work, no matter what direction bones are pointing.

If the problem was due to IK, then yes.. It should work. Once LW has the ability to select the order of which commands (IK, expressions, targeting) are calculated, it will be fixed.

On the other hand, if the problem was due to gimble lock then.. No.. It's working as it should. I think LW9 will have something other than euler rotation. Um.. the name escapes me at the moment. But keep in mind that targeting only occurs on two axis. The third, bank, more or less determines "which side is up." And because a bone inherits the rotation of it's parent, if it's facing upside down, it's gonna flip upright.

Apart from adding a re-orienting bone like I suggested earlier, another solution would be to track with more than one bone -using IK instead of targeting. If you restrict tracking on one axis per bone, you can sometimes get more control over the joint's behavior. Have one bone IK solve only on the heading, then it's child only solve on the pitch.

Here's another way to look at it: A bone that targets on two axis at once functions like a ball-and-socket joint. But when you boil rigs down to their most basic elements, they are best when they work like machines; swivel and hinge rotations only. How would NASA build an arm? But this is all theory.. There is no right and wrong way to rig. Just whatever works best for you.

EDIT: Quarternion! I just remembered.. :) I won't be using Quarternion because editing the data in the graph editor is so confusing to me. There's X, Y, Z and what's this W thing? But it's nice to have it for those who like it.

kevman3d
03-04-2006, 10:50 PM
It sounds more like you've possibly used RPR on it prior. RPR realigns the pivot rotation to 'zero' out the rotations (its one of those bones where you shouldn't use RPR (as its being automatically taken care of by targeting, etc)).

Even if you didn't RPR, I would do this just in case it helps...

Simply select the bone, select 'Rotate Pivot' in the modify tab, and then set HP & B to 0 so that Targetting can calculate the rotation correctly from a 0 start point. Targetting should correct itself.


Kev.

CGTalk Moderation
03-04-2006, 10:50 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.