Jump to content
Hash, Inc. Forums

mutual aim ats?


robcat2075

Recommended Posts

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.

Link to comment
Share on other sites

  • Hash Fellow
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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Hash Fellow
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?

Link to comment
Share on other sites

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):

 

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Hash Fellow
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.

Link to comment
Share on other sites

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.

 

eg if

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

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

 

perhaps?

Link to comment
Share on other sites

  • Hash Fellow
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.

 

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

 

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

 

would be an accurate summary of the problem.

 

Aim At is not an orientation constraint.

Link to comment
Share on other sites

  • Hash Fellow

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

  • Developer
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 :-)

Link to comment
Share on other sites

  • Hash Fellow

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.

Link to comment
Share on other sites

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:

 

heh, heh - nyah, nyah

 

:yay:

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

  • Hash Fellow
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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Admin
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. :)

Link to comment
Share on other sites

  • Hash Fellow

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.

Link to comment
Share on other sites

  • Admin

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.

Link to comment
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...