Help - Search - Members - Calendar
Full Version: mutual aim ats?
Hash, Inc. Forums > Technical Direction and Development (Learning Animation:Master) > A:M Rigging & Relationships
robcat2075
It ought to be possible to have two separate bones Aim At each other because that would not be a true circularity.

But A:M doesn't allow it. hmmm...


Meowx
Perhaps duplicate the bones, constrain the copies to the originals (translate to and orient like) and have the original bones aim at the copies?
Gerry
Yeah, there's got to be a way. We're depending on you to figure it out, Robert!
itsjustme
QUOTE(robcat2075 @ Mar 3 2011, 01:07 PM) *
It ought to be possible to have two separate bones Aim At each other because that would not be a true circularity.

But A:M doesn't allow it. hmmm...


Why wouldn't it be a circularity? You could work around it, but it would take more than two bones, I'm thinking.
itsjustme
Something like this, maybe.


robcat2075
QUOTE(itsjustme @ Mar 3 2011, 05:54 PM) *
Why wouldn't it be a circularity?



I see it this way...

An AimAt points Bone A towards the base of Bone B. The orientation of B has no bearing on where its base is, so no matter where B is pointed that doesn't enter into the calculation of Aiming A at B.

We would all agree on that.

Going backwards should be true too. An AimAt to point Bone B to Bone A aims B at the base of Bone A. Where Bone A is pointed doesn't affect where its base is, so no direction of A is needed to make B point to A. A can point anywhere , even at Bone B, and it doesn't enter into the task of pointing B at A.

There really is no infinite circularity in pointing two bones at each other.
itsjustme
QUOTE(robcat2075 @ Mar 3 2011, 10:43 PM) *
QUOTE(itsjustme @ Mar 3 2011, 05:54 PM) *
Why wouldn't it be a circularity?



I see it this way...

An AimAt points Bone A towards the base of Bone B. The orientation of B has no bearing on where its base is, so no matter where B is pointed that doesn't enter into the calculation of Aiming A at B.

We would all agree on that.


Nosir, I don't agree...it is part of the calculation (quaternion math). It would be a circularity, Robert.


robcat2075
QUOTE(itsjustme @ Mar 3 2011, 11:02 PM) *
Nosir, I don't agree...it is part of the calculation (quaternion math). It would be a circularity, Robert.


I just tried it.

If I make Bone A AimAt Bone B. There is no rotation of Bone B that will ever affect Bone A. You can rotate Bone B to any direction and it doesn't change anything about Bone A.

Bone A does not need rotation information from Bone B to point at Bone B.

Can you show me a case where the rotation of Bone B will affect Bone A?
itsjustme
QUOTE(robcat2075 @ Mar 3 2011, 11:10 PM) *
QUOTE(itsjustme @ Mar 3 2011, 11:02 PM) *
Nosir, I don't agree...it is part of the calculation (quaternion math). It would be a circularity, Robert.


I just tried it.

If I make Bone A AimAt Bone B. There is no rotation of Bone B that will ever affect Bone A. You can rotate Bone B to any direction and it doesn't change anything about Bone A.

Bone A does not need rotation information from Bone B to point at Bone B.

Can you show me a case where the rotation of Bone B will affect Bone A?


Based on my limited knowledge of quaternions (used internally by A:M), you need a point in space (the origin) and a vector. Here is a quote that I think applies (from here):

QUOTE
A quaternion represents two things. It has an x, y, and z component, which represents the axis about which a rotation will occur. It also has a w component, which represents the amount of rotation which will occur about this axis.


So, that tells me that the origin is in every calculation (for every bone). I'm not a math expert, so perhaps someone could correct me.
3DArtZ
been a while since I have even opened A:M but could you do this with 2 bones and 1 null?
Make the null translate to both the bones, that would put it directly inbetween both bones.
then have each bone aim at the null?
actually that might be a circularity too as the null would want to know the base information of both bones....

Mike Fitz
robcat2075


QUOTE
A quaternion represents two things. It has an x, y, and z component, which represents the axis about which a rotation will occur. It also has a w component, which represents the amount of rotation which will occur about this axis.


I read that as being all about axis of rotation not axis of translation.

We can look at our quaternion channels and see that translating a bone in space does not change them at all.

Try this...

two people standing in a room.

The first person can always aim at the second no matter how the second is aimed. If we now tell the second person to always aim at the first person, the first person can still continue to always aim at the second person. Nothing about the second person's aim has anything to do with how the first person will aim himself. He doesn't need to know the second person's aim direction before he can aim himself.

And vice versa.
NancyGormezano
I am going to guess and suggest that it is said to be circular because of the order in which things get evaluated/computed in A:M, regardless of what type of constraint.

CODE
eg if

A=f(B) &
B=f(A)

then the evaluation of B=f(A=f(B)) would lead to infinite loop (recursion?)


perhaps?
robcat2075
QUOTE(NancyGormezano @ Mar 4 2011, 12:38 PM) *
I am going to guess and suggest that it is said to be circular because of the order in which things get evaluated/computed in A:M, regardless of what type of constraint.

CODE
eg if

A=f(B) &
B=f(A)

then the evaluation of B=f(A=f(B)) would lead to infinite loop (recursion?)


perhaps?



No, because each bone has two separate properties, location and direction. Its direction doesn't contribute to its location and its location doesn't contribute to its direction

Bone A points to the location of Bone B. It doesn't need to know anything about the direction of Bone B to do that. The circularity stops right there. The direction of Bone B can be anything, even automatically pointing back to Bone A and it doesn't change where Bone A should point.


If I was trying to constrain the orientation of two bones to each other then

CODE
A=f(B) &
B=f(A)


would be an accurate summary of the problem.

Aim At is not an orientation constraint.
robcat2075
how about this. Let's say you and I are both wearing pants and our left pockets represent "translation" and our right pockets represent "rotation".

What's in your left pocket doesn't affect what's in your right pocket. You can add or subtract anything from either pocket and it doesn't change what's in the other. Same pair of pants but there's no relationship between the pocket contents.

Likewise Bone rotation and translation are independent of each other.

Let's say we add a constraint on each other so that we have to keep what's in our right pockets equal to what's in the other person's left pocket.


If you have a dollar in your left pocket I need to put a dollar in my right pocket but it doesn't change what's in my left pocket (half a snickers bar) which is what you need to match in your right pocket.

When you put a half a snickers bar in your right pocket it changes nothing about your left pocket which is all my right pocket cares about.
NancyGormezano
I am suggesting that A:M does not provide a special case check for "aim at" when computing position and orientation of a bone that has constraints, regardless of whether you think it should or not.

I am suggesting that the position & orientation of a bone in the model space are computed at the same time and that it is probably ONE function/procedure call that computes the position & orientation of each bone, according to a precomputed hierarchy. That is why I suspect it might be considered recursive. And obviously I have no inside knowledge of how A:M is programmed.

(excuse my ignorance as I'm rusty with programming, do not know C, or any object oriented language, and come from assembly, basic, fortran language background)
yoda64
QUOTE(robcat2075 @ Mar 4 2011, 06:10 AM) *
I just tried it.

If I make Bone A AimAt Bone B. There is no rotation of Bone B that will ever affect Bone A. You can rotate Bone B to any direction and it doesn't change anything about Bone A.

Bone A does not need rotation information from Bone B to point at Bone B.


This is correct , for the AimAt constraint You don't get a circularity .
The reason why this wasn't allowed in the current version, is that the AimAt is using a more general function for filling the combobox (where You can select the target bones), and for the
reason to avoid circularitys for other constraint types) not all bones are added to this combobox .
For the AimAt I have changed this now (simply with overloading the function call ..).

Ps.
Seen yet that Nancy has explained this before me :-)
robcat2075
Obviously something in the program is stopping a mutual Aim At but the reality is that two Aim Ats are not a circular relationship like two Translate To's would be or as two Orient Likes would be.

Nothing about the aiming of one bone has anything to do with the aiming of the other.

You aim at a location, not another aim. The location of the base of a bone does not change because it is aimed somewhere.
NancyGormezano
QUOTE(yoda64 @ Mar 4 2011, 11:39 AM) *
The reason why this wasn't allowed in the current version, is that the AimAt is using a more general function for filling the combobox (where You can select the target bones), and for the
reason to avoid circularitys for other constraint types) not all bones are added to this combobox .
For the AimAt I have changed this now (simply with overloading the function call ..).

Ps.
Seen yet that Nancy has explained this before me :-)


clap.gif

heh, heh - nyah, nyah

yay.gif

robcat2075
QUOTE(itsjustme @ Mar 3 2011, 06:04 PM) *
Something like this, maybe.


Thanks, BTW.
robcat2075
Thanks also, Steffen!

I knew I wasn't crazy.
HomeSlice
QUOTE(robcat2075 @ Mar 4 2011, 11:55 AM) *
I knew I wasn't crazy.

Well, I wouldn't go that far tongue.gif
mtpeak2
This is possible in A:M, there is no circularity. After setting up the first "aim at" constraint, set the enforcement to 0 percent, then setup the other constraint. After both are setup, set the first ones enforcement back to 100%. (tested in a pose and action)
robcat2075
QUOTE(mtpeak2 @ Mar 4 2011, 04:32 PM) *
This is possible in A:M, there is no circularity. After setting up the first "aim at" constraint, set the enforcement to 0 percent, then setup the other constraint. After both are setup, set the first ones enforcement back to 100%. (tested in a pose and action)


Very clever, Mark.

I knew you weren't crazy, either.
itsjustme
QUOTE(robcat2075 @ Mar 4 2011, 05:25 PM) *
QUOTE(mtpeak2 @ Mar 4 2011, 04:32 PM) *
This is possible in A:M, there is no circularity. After setting up the first "aim at" constraint, set the enforcement to 0 percent, then setup the other constraint. After both are setup, set the first ones enforcement back to 100%. (tested in a pose and action)


Very clever, Mark.

I knew you weren't crazy, either.


Well, whatayaknow...I bow to your superior mental skills, guys! I thought that the origin was necessary in the quaternion calculation...guess I'll have to take a night class or something.
Rodney
QUOTE
This is possible in A:M, there is no circularity. After setting up the first "aim at" constraint, set the enforcement to 0 percent, then setup the other constraint. After both are setup, set the first ones enforcement back to 100%. (tested in a pose and action)


Very nice Mark.
That's such an elegant solution.
So simple I never would have thought of it.

Added: In experimenting, I'm still not quite there. I've gotten circularity errors after the model is dropped into a Chor and animated.
I'm sure I'm making this more complex than necessary. (For this error it looks like I constrained two models to aim at each other in a Choreography)

Update: After getting rid of the extra stuff that I didn't need the dual Aim At constraints are working like a charm. A screen refresh issue was making it seem like one of the constraints wasn't working... which is odd because the other one displayed fine. Dropping the Model into the Chor had them both working and the Enforcement percentages animating. smile.gif
3DArtZ
Nice one Mark.
3DArtZ
so... now what would one use this for? Im thinking it could make animating a spinal cord pretty ez?
whatelse?
robcat2075
how about...

-two dish antennas on separate vehicles that always face each other
-two planetary bodies orbiting each other, keeping the same face to each other
-it might simplify IK spine rigging, as you suggest

-a rubber band stretched between two moving fingers

- in my immediate case I had a long series of bones each one with an Aim At to the next. But the last one had nowhere to aim except the previous bone. I ended up using another workaround that didn't require the last bone to point to anything.


It's a rare need. Obviously we've been rigging fine without it for 15 years now, but i questioned that it had to be impossible.
mtpeak2
This also works with an "Aim Roll At" and a combination of an "Aim At" on one bone and an "Aim Roll At" on the other bone.
Rodney
One thing I've noted to self during experimentation is that this could be useful for gaining (free) secondary movement and aiding with moving holds.
For instance, I constrained Thom's forearms together at 33 and 66 percent respectively and played around with each arm.
As they are aiming at each other the opposite arm moves in an attempt to keep up.

If I were smarter I'd try to build some kind of self constraining muscle but I think I've already surpassed my level of competence on this one.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.