Bone names and limits

General discussion about JPatch

Postby dcuny » Wed Nov 02, 2005 9:59 pm

Sascha wrote:Ok, ok, ok,,, I guess you're right again ;)
Don't tell my wife... :P

But I won't abandon my "anchor" idea that easily...
Yes, it's a good idea. Being able to attach objects to other objects is very important.

I found an interesting reference here that shows how this can be done in A:M. Basically, you constrain an object to a bone using the Translate To and Orient Line constraints. One problem is that's potentially a "snap" as the constraints come into effect, so there's a "compensate mode" you can turn on that eases the transition.

Not quite the same thing, but it achieves a similar effect. As much as I want to avoid having to work with constraints, I have to admit that they can be pretty useful. (It's not so much that I want to avoid working with constraints as I want the rigging system to be understandable by mere mortals).

What if our character enters a e.g. paternoster elevator or steps on an escalator? He could finish the "ease out" of the walk cycle or continue to walk, but this time relative to the paternoster's or escalator's space, not to world space...
I think there are two things going on here: the character easing out of a walk cycle, and the character being locked to an elevator/escalator. I'm not sure they're actually related... :?

IIRC it was on the A:M tutorial page with those flash/shockwave screen-captured tutorials. I think it was "It's a Pitch".
OK, it's not really related to the walk cycle, but it is related to locking joints into position.

I think it was after seeing that video that I posted my request that JPatch be smart about applying beizer/linear curves. I'm not sure why A:M doesn't automatically try to correct overshoot - I suppose when you implement it, you'll find out. :D

I think I'll start with implementing it the "standard" way, as you suggested. I can always later add the "anchoring" system - No one is forced to use it after all, if you're happy with the default behavior you could leave the anchor at the model's "origin".
I think an IK system (again, AoI springs to mind) that allows feet to be locked to the ground (or another object) would pretty much cover the remaining cases. But you can clarify this later...

If you can implement a simple walk-cycle system, I think it would be very helpful for the IRTC animation. Specifically, I'm thinking about the scene where the robot is running around going beserk.

If that doesn't happen, you can still paste in the walk cycle manually. You can also frame a number of shots so the robot's feet aren't visible, and avoid the problem that way.

I wasn't very impressed by the system: The IK solver came up with poses that looked very uncomfortable (I think A:M has no way to define joint limits), and well, there was this overshoot issue.
Well, I know that A:M bones have spherical limits.

The sad reality for me is that just about any IK system I've played with, I've managed to get the character hopelessly entangled by dragging a bone into an implausible position. This is (I assume) why you have lots of control bones littered about the rig, to constrain the rig bones into behaving themselves:

Image

I'm probably expecting too much out of the IK systems, like automatically recognizing that I'm doing something really stupid, and not collapsing the IK chains into a twisted mess.

There are lots of articles on why using only IK results in poor animation. While there are ways to coerce the system into giving a more reasonable solution, I agree with your earlier comment that you'll need to fine tune the pose with FK.

Problematic or not, IK is certainly a feature I wouldn't want to do without! :o
Last edited by dcuny on Wed Nov 02, 2005 10:36 pm, edited 1 time in total.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Wed Nov 02, 2005 10:27 pm

While Googling about for information on A:M's joint limits, I ran across these graphics which show what A:M's "stride ruler" in action:

Image Image
Image Image

You can see a little "ruler" in the middle, marking from 1..15. When you are at the beginning of your animation, you set that point:

Image

When you reach the end of your stride, you mark that point:

Image

A:M automatically calculates the stride length for you:

Image

You can also use it to measure rotations:
A:M Manual wrote:Stride length can also be used to keep round objects such as wheels from slipping. At frame “0”, move the front of the stride length ruler to the center of the wheel. Advance frames to where the wheel completes one revolution. Move the back of the stride length ruler to the perimeter of the wheel.

Since the ground "rolls" along at the speed of the stride length, you can also use it as a visual reference to make sure that your limbs aren't slipping.

Here's a screenshot from Pixelburg, along with an explanation:

Image

The Animation:Master Glossary wrote:Stride Length:Aka „Step Length“ is a setting of an Action. When you want a character to walk (or run, or jump, or drive) along a path, you have to tell AM, how far your object should advance on it's path with every step it takes. If the progress on the path does not fit to the step length, the characters feet slip over the ground in an unnatural looking way. HowTo: select the action in the PWT (step#1) and switch the „Has Stride Length“ setting to „ON“ (step#2). A little ground-grid is displayed beneath your character. If you click on the grid, two little sqare handles indicate the extremes of a step – drag them to match your charater's action (step#3). Finally adjust the time, each step lasts (step#4). See image on the right for a step-by-step screenphoto.

Hint: If the feet slip forward with every step, then the stride length is too big (decrease it!). If the feet slip backward with every step, the stride length is too small (increase it!).

Very slick. I know you're not out to clone A:M, but I think the stride length tool is something that they definitely got right. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Nov 03, 2005 11:31 am

Ok, thanks for all the infos!

I guess it's really too early for a decision about how to proceed. In a first step, the modeler will allow to create morphs (I am about to implement morphs with multiple targets), bones with DOFs (currently only rotation DOFs, with definable rotation-limits), and each rotation DOF may have a "smartskin" morph associated with it.
Assigning controlpoints to bones currently works this way:
You can select any number of controlpoints and any number of bones. Clicking on "auto-assign points to bones" will assign each selected controlpoint to the closest selected bone. This way, the same tool can be used for coarse auto-assign and for fine-tuning. Select everything and click on "autoassign..." and all points will be assigned to the closest bone. If you're not happy with a group of points, select them, select the bone (or bones) you'd like to have them bound to and click on "autoassign..." again.
I think this is the most intuitive solution and works surpisingle well. I doubt that my initial idea with the "bone influence radius" is neccessary at all.

The animator will be able to pose a model (morphs and bones) using sliders, and in a later step using handles to potision the bones.

I need to do a lot of experimentation before I can make up my mind about how to proceed and how to implement IK and actions. But finally JPatch has come to a point where developing it becomes more interesting than the boring bug-fixing phase :)

PS: I think you've convinced me that the stride-length approach is superior to my "anchor" approach: The character might be running or jumping - and during the fly-phase he of course isn't locked to the ground...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Nov 03, 2005 8:01 pm

In a first step, the modeler will allow to create morphs (I am about to implement morphs with multiple targets), bones with DOFs (currently only rotation DOFs, with definable rotation-limits), and each rotation DOF may have a "smartskin" morph associated with it.
That's certainly enough to do some solid animation with. :D

You can select any number of controlpoints and any number of bones. Clicking on "auto-assign points to bones" will assign each selected controlpoint to the closest selected bone.
OK, that seems straightforward.

The animator will be able to pose a model (morphs and bones) using sliders, and in a later step using handles to position the bones.
You had mentioned that having to move bones with sliders was a real pain. One possible hack that came to mind would be to add a FK mode to the animator. In FK mode, you can select joints by clicking directly on them. A tool would then pop up at the joint, and you could adjust it with the mouse. When you were done, you would close the tool, and you could select another joint.

One possibility for the tool would be a fixed-size rotate tool, positioned at the center of the bone:

Image

This might be a bit much to code (I'm thinking about something quick and dirty); another option would be Messiah-style sliders:

Image

That said, since you've already got something that works, there's probably not much point in wasting any time doing this. :?

I need to do a lot of experimentation before I can make up my mind about how to proceed and how to implement IK and actions. But finally JPatch has come to a point where developing it becomes more interesting than the boring bug-fixing phase.
Yay! (Hurry up and post a version we can play with! ;))

I think you've convinced me that the stride-length approach is superior to my "anchor" approach: The character might be running or jumping - and during the fly-phase he of course isn't locked to the ground...
Or a fish swimming... or even a robot hammering in nails as it rolls up the wall...
Last edited by dcuny on Thu Nov 03, 2005 8:17 pm, edited 1 time in total.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Nov 03, 2005 8:12 pm

One possibility for the tool would be a fixed-size rotate tool, positioned at the center of the bone:
This might be a bit much to code


No way! The rotate tool is now able to rotate everything. The problem that I see is that some bones will have only one DOF, and the rotate tool would just look odd on them. Also note that the order of the DOFs does matter. E.g. there is a huge difference if you first bend and then twist (like on the elbow) or first turn and then bend (like the neck). I'll simply add a handle per DOF that can be used to rotate the bone around the DOFs axis - should be straightforward to implement.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Nov 03, 2005 9:30 pm

OK, that's how it works in A:M and AoI. I can't recall what Blender does, but it currently doesn't support DOF.

One thing that appears to be missing is the ability to have child bones that aren't directly attached to the parent. For example:

Image

The prior picture is supposed to show several different chains: arms, ears and backbones. If you look closely, you'll notice that there isn't a bone connecting the arms to the backbone, or the ears to the headbone.

This is typical of a lot of rigs I've seen.

When you move the head, you want the ear bones to rotate along with the head bone. Likewise, when you move the backbone, you want the arms to bend. But JPatch doesn't know that if the bones aren't connected.

Now, I know you can attach a bone between the head bone and the ears with no DOF, but that clutters things up. Besides, I'm lazy, and don't want to accidentally assign points to the "connector" bones.

In Blender, you can do this by parenting the ears to the head bone. It's a confusing operation, because I can never remember if the first or second object that was selected is the parent, or the parented object.

Image

In messiah:animate, you can turn off the "Align to Parent Z Length" attribute and then move the bone into position.

I thought perhaps this might work in JPatch by dragging the child bone underneath the parent bone on the list, but that obviously doesn't work.

One thought that came to mind would be to create "connector" attribute for bones:

Image

The bones display as lines, so you can see there's a connection. They have no DOF, so you can't accidentally manipulate them. Finally, they're ignored by the "autoassign" button. So basically, you don't have to re-engineer bones to get them to work.

Ooops... I just noticed I made the wrong bones into "connector" bones. So there should be a way to turn them back into "real" bones.

Is this overengineering the solution? From a user interface point of view, you could just have a "Add Connector" button that works like the "Add Bone" button.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Nov 03, 2005 10:34 pm

Yes, I've seen that in A:M.

But I think it's not neccessary in JPatch. Here's why:

JPatch's bones per default have no DOFs - if you want that a bone can rotate you'll have to add DOFs. To prevent the "unused" bones from polluting the screen I could add an option that hides all bones with no DOFs, or (as you showed) displays them as thin line connecting to the parent.

Now, what if a point becomes (auto)assigned to such an "unused" bone? It doesn't matter. Since the bone itself has no DOF, it's transformation matrix is inherited from the first upstream bone that has DOFs - for the point it would make no difference if it is attached to this or the parent bone.
The only difference is that when you later decide to add a DOF to the bone, the points will get the matrix from it - I guess that's quite useful.

So technically there is no difference between a bone and a connector (in JPatch!) - a connector would be a bone without degrees of freedom. I'd say the option to not render those bones (or render them as lines) should be sufficient.

What do you think?

PS: Trying to read your mind, you might say that you're lazy and don't want to add DOFs to bones at all :P - but: If all bones had 3 DOFs (and possibly a 4th for stretching it) per default, you'll most likely have more work to delete the unused DOFs and fine-tune the remaining ones. There are quite a few bones with just one DOF (knees, elbows, fingers,...)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Nov 03, 2005 11:27 pm

Sascha wrote:Trying to read your mind, you might say that you're lazy and don't want to add DOFs to bones at all
Sorry, your mind reading isn't working today. ;)

I'm in no way against DOF in bones - they're essential for IK to work properly, and they're even useful for FK (to stop sliders from zipping to wacky values).

It had occured to me that possibly there was a 1:1 correspondance between "connector" bones and bones with no DOF, but this isn't always the case.

For example, consider a "root" bone that an object may be attached to. It may have no DOF (you might not want to rotate it), you don't want to attach any points to it... But you don't want it to appear as a connector bone.

Similarly, you might happen to have a bone in the middle of a a chain that itself has not DOF, but the bones attached to it do. In that case, you'd still want to attach points to that bone (so they don't rotate when the ends rotate), so it's not really a connector.

Another issue is that by making a connector dependant on the zero DOF, it might not be obvious to the end user how to create connectors. That's why I think having an "Add Connector" button is a good idea - it makes it dead simple for the user to figure out how to add connections between bones.

Finally, I suspect that it would be simpler from an implementation perspective to have a single boolean value to check (isConnector = true) instead of making it dependant on several values.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Fri Nov 04, 2005 10:30 am

Sorry, your mind reading isn't working today.

:shock: How could that happen! My apologies. Looks like I need more practice, this mind reading business is quite tricky, especially at long distance :)

Another issue is that by making a connector dependant on the zero DOF, it might not be obvious to the end user how to create connectors.

I tend to disagree. If we take our own skeleton as a reference, it should be obvious that a bone is always connected to another bone - there are no free floating bones. But there are some bones that can't be moved (the thorax, for example) - so everybody should be familiar with the concept, and it should be quite obvious that bones are used to connect to other bones.

To the contrary, I found it quite surprising that in A:M modles some bones are bound to other bones without a "physical" connection.

Similarly, you might happen to have a bone in the middle of a a chain that itself has not DOF, but the bones attached to it do. In that case, you'd still want to attach points to that bone (so they don't rotate when the ends rotate), so it's not really a connector.

I'm afraid you've lost me here :?
If a bone is in the middle of a chain it has a parent and at least one child. Because they form a hierarchy, the bone in question will inherit the transformation matrix from its parent bone, may apply its own transformations (depending on its DOFs) and would in turn pass that matrix to its children. There is no way for a bone to not inherit the transformation from its parent - that's what a hierachical bone system is all about!

For example, consider a "root" bone that an object may be attached to. It may have no DOF (you might not want to rotate it), you don't want to attach any points to it... But you don't want it to appear as a connector bone.

This is the only case where a bone (or connector) is not neccessary: All orphaned bones are implicitly attached to the model's space (you can think of it as an imaginary, invisible root bone). The model's space in turn is transformed by the animator-application into world space, and arbitrary transformations may by applied (you can position, orient and scale the model, and in theory you could even apply non-uniform scaling or shearing).

IMHO the distinction of a bone's parent (the one it inherits the transformation from) and its "attachement" or "connection" (the visual representation) is counter intuitive and there's nothing to gain from it. If you want to connect the shoulder to the top of the spine, just add a bone (with no DOF) between them. This way the system is straight forward - the entire tree hierarchy has just one type of nodes: bones. I agree that it would make sense to be able to display mere connector bones differently (grayed out, outline only, thin lines, or not at all).

What could be gained if there was a distinction between the "connected" and the "parent" bone? Would you connect a bone to another bone than its parent in the hierarchy? Even if there is a way to make this work, I can't think of any practical application.

Finally, I suspect that it would be simpler from an implementation perspective to have a single boolean value to check (isConnector = true) instead of making it dependant on several values.

Well, if (listDofs.size() == 0) is neither hard to code nor computationally expensive... :wink:


Here's how the system works in detail:
Each dof has a transformation matrix associated with it. The effects of multiple DOFs on a single bone "add up" (the order is important) and transformations are inherited from parents.

If a DOF has to compute its transformation matrix, if first checks if it has an upstream ancestor DOF on the same bone. If yes, it uses the transformation matrix of that DOF as the basis. If not, it recursivley searches through it's bones upstream ancestors until it finds a bone that has DOFs defied and uses the transformation matrix of the last DOF of that bone as the basis - if not, it uses the identity transform as the basis.
It then computes its own transformation (the DOF has an axis and an angle) and multiplies it with the "basis" matrix found in the previous step.

After the matrix of a DOF has been computed it (an its inverse) are cached for speed reasons. Subsequent calls to getTransformation() will return the cached value.

If a DOF's axis or angle has been changed, it sets a flag in all its downstream descendants (that are all DOFs on the same bone that come after it and all DOFs in all child bones, their child bones, and so on).
The flag will tell the DOFs that their cached matrix is invalid and that it has to be recomputed upon the next getTransformation() call.

Bones do have a getTransformation() method. It will return the transformation matrix of their last DOF. If the bone does not have any DOFs, it will recursively search upstream and return the transformation matrix of the last DOF in the first bone it finds that has DOFs, or identity if no bones with DOFs are found.

A controlpoint that is assigned to a bone can get its transformation matrix by calling getTransformation() on the bone it is attached to (this is how it is implemented right now). If the bone is not "fully" attached to the bone, it should call getTransform on the bone's parent bone, and compute its "weighted" transformation according to the per-DOF-weight it has. I'll implement that, but I'll need a similar caching strategy like for the DOFs to speed up everything.

What happens in the animator (not yet implemented):

The first step is to apply all morphs (no matter if "normal" or "smartskin" to the model's controlpoints.
The second step is to apply the pose (that is, all the DOFs rotations).
The third step is to transform the posed model from model into world space (using the position, orientation and scale motion-curves for that model).

All points store the referene position of that particular controlpoint or bone. To get their actual (posed) positions, they will be transformed with the points "pose" transformation matrix. This matrix will be cached and only recomputed if the pose changes. Similar, if a point is modified (moved, scaled, rotated), this modification is transformed with the inverse of that "pose" matrix and applied to the reference position.

The DOF system already works that way, the morphs unfortunately not and I have to change that: I naively thought that the morph could be applied by adding the vector and unapplied by subtracting it since only additions and subtractions are involved. This is however not true - adding a large number to a small number and subtracting it again will, using floating point math, not yield the same small number, so repeated applying/unapplying of morphs will slowly deform the model, so I have to change that.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Fri Nov 04, 2005 8:19 pm

Sascha wrote:I tend to disagree. If we take our own skeleton as a reference, it should be obvious that a bone is always connected to another bone - there are no free floating bones. But there are some bones that can't be moved (the thorax, for example) - so everybody should be familiar with the concept, and it should be quite obvious that bones are used to connect to other bones.
No, I agree with you there.

The problem (in my mind) was that there is a related attribute of connector bones: they don't have any points connected to them.

On consideration, I could see that this isn't always the case. So I guess what I'm asking for is actually two features:
  • By default, display bones with no DOF as lines. This simplifies the view for the animator, and makes it clear what bones they can manipulate, and what bones they can't manipulate. As you suggested, the user could turn this option off.
  • Add a "don't attach points" attribute to bones. That way, you can make sure that autoassign won't attach points to a bone.
In the user interface, I'd like to have an "Add Connector" bone that creates a bone with zero DOF, and with the "don't attach points" attribute set to true.

Here's how the system works in detail...
One of these days, I'm going to have to start dealing with matrices instead of passing pitch/yaw/roll parameters around. (But not today. ;))

... adding a large number to a small number and subtracting it again will, using floating point math, not yield the same small number...
Oh, lovely. :roll:
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Fri Nov 04, 2005 8:35 pm

Sascha wrote:JPatch's bones per default have no DOFs
Ooop, I just noticed that.

No, this is a bad idea. In Anim8or, the bones by default are locked, with no DOF. Invariably, a new user will put together a rig, and then be completely baffled when the rig refuses to move.

In contrast, Blender and AoI let you create rigs and play with them immediately. It's much more intuitive. You can always add DOF later. If the user wants a locked bone, they can click the "Add Connector" button. :)

It would also be nice to have a set of predefined joint types that the user could select from, such as "hinge" or "ball and socket", or even "left knee" (that would default to a reasonable default range of motion).
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Fri Nov 04, 2005 9:04 pm

On consideration, I could see that this isn't always the case. So I guess what I'm asking for is actually two features:

* By default, display bones with no DOF as lines. This simplifies the view for the animator, and makes it clear what bones they can manipulate, and what bones they can't manipulate. As you suggested, the user could turn this option off.
* Add a "don't attach points" attribute to bones. That way, you can make sure that autoassign won't attach points to a bone.

The display thing is easy - I wouldn't turn on this option when building the skeleton (new bones have no DOFs and won't be shown then) though.
A "don't attach points" attribute would be easy to implement. I still don't understand why assigning points to such connector bones would be a bad thing. In fact those non-movable bones could be used to yield better auto-assign results...

One of these days, I'm going to have to start dealing with matrices instead of passing pitch/yaw/roll parameters around.

Yes, that's a good idea. It makes live a lot easier (and the javax.vecmath classes provide basically everything you need to deal with them - e.g. setting up a rotation matrix from and axis/angle pair, etc.)
There are many articles about matrices and how they are used in 3D graphics out there (e.g. search for "linear algebra") - it's far easier than a first look might make you feel!

Quote:
... adding a large number to a small number and subtracting it again will, using floating point math, not yield the same small number...
Oh, lovely.

I mean, it was quite obvious to me that you can't rotate a point, rotate it back and expect it to have exactly the same position again. There is trigonometry and a lot of multiplication involved, so the result can't be exact. JPatch always took care of that: when you e.g. begin to rotate an object using the rotate tool, it stores it's current positions. If you update the rotation (by dragging with the mouse) the new rotation is always computed based on the stored original position, so the results are as exact as possible.

Sadly, the same thing is true for (floating point, not integer) additions and subtractions as well. 32-bit floats use (IIRC) 24 bits of precision (the remaining bits are used for the exponent). So, if you add 1'000'000.0 (one million) to 0.000'000'1 (one millionth) you'll get 1'000'000.0 - and if you subtract the million again, you'll get 0.0 - the millionth is a victim of rounding due to the limited precision.
Another funny thing about floats is that they store numbers in binary (d'oh) - but that means that e.g. the decimal number 0.1 cannot be represented exactly as a float (just as 1/3 can't be represented in decimal)!
Here's an example:
Code: Select all
float f = 0.0f;
for (int i = 0; i < 10; i++)
    f += 0.1f;
System.out.println(f);

Try it out - it will print 1.0000001 :)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby sascha » Fri Nov 04, 2005 9:13 pm

JPatch's bones per default have no DOFs
Ooop, I just noticed that.

No, this is a bad idea.

Ha! So the mind reading did work! :P

Well, without DOFs a bone won't move. All I can offer is a mode that will per default add all 3 DOFs of rotation to a new bone - but that model will behave strangly, as you could e.g. rotate the elbow in unnatural ways. Just removing the DOFs won't solve the whole problem, because the DOF order does matter - so you'd need to resort the DOFs for some bones as well. This will become messy...
Having to add the DOFs manually has one great advantage: It makes the user aware of what he's doing: If you first add a "twist" DOF followed by a "bend" DOF, that's what you get: You can twist and then bend the bone. If you first add the "bend" and then the "twist" DOF, you can bend and then twist the bone - which does make a difference!

I can add a "all bones will ship with 3 default DOFs attached" mode, but this will cause a lot of confusion...

To start with, JPatch could include a biped-skeleton for humans and a quadruped-skeleton for animals, with the right DOFs attached and reasonable limits. If you have a model that is human like, you could load the default biped-skeleton, drag the bones in place, click on "auto-assign" and are ready to go. Creating custom skeletons will require knowledge about how the DOFs work.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Fri Nov 04, 2005 9:38 pm

Sascha wrote:All I can offer is a mode that will per default add all 3 DOFs of rotation to a new bone - but that model will behave strangly, as you could e.g. rotate the elbow in unnatural ways. Just removing the DOFs won't solve the whole problem, because the DOF order does matter - so you'd need to resort the DOFs for some bones as well. This will become messy...
Generally, people will remove DOFs, but only after they've created the initial rig and played with it a bit. Personally (and I could be wrong here!) I've found it more intuitive when programs leave the DOFs unlocked by default.

I still don't understand why assigning points to such connector bones would be a bad thing. In fact those non-movable bones could be used to yield better auto-assign results...
It's not a bad thing, I just think that by default, most of the time that's not what you want. Since you can toggle it off in the bone editor, it shouldn't be a big deal. You might also have it as a user-defined option.

Having to add the DOFs manually has one great advantage: It makes the user aware of what he's doing: If you first add a "twist" DOF followed by a "bend" DOF, that's what you get: You can twist and then bend the bone. If you first add the "bend" and then the "twist" DOF, you can bend and then twist the bone - which does make a difference!
Yes, it makes a difference. But trust me - the user won't get it until things start going wrong.

You don't necessarily want to have the DOF order based on the order that the user adds it, because that's not always right, either. It's a bit messy to edit that option, and (even worse) there's not necessarily anything in the display to indicate what order you've set the DOF.

I think it would be better - and simpler - to have a dropdown where the user can select the order. I think I've seen this in A:M, as well as other programs.

There are many articles about matrices and how they are used in 3D graphics out there (e.g. search for "linear algebra") - it's far easier than a first look might make you feel!
Oh, I've got a fairly good grasp of it, it's just that old habits are hard to break. I still tend to code most of my stuff in the DOS editor. Java and .NET languages are the exceptions - since they've got such huge class libraries, it's virtually impossibile to code these without intellisense (or a large stack of documentation).

Try it out - it will print 1.0000001
I'm more than familiar with this issue - I've written a Basic interpreter. The main place it impacts the code is in the equality tests. :?

You know, I'm sort of suprised you're not getting any feedback from other users. I know that A:M folk occasionally pop by to see what sort of progress you're making, and I'm sure other people with experience with other Animation systems have opinions as well. After all, the more feedback you get at this point, the more mistakes you can avoid in the design! :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby squirrelhavoc » Fri Nov 04, 2005 9:49 pm

dcuny wrote:You know, I'm sort of suprised you're not getting any feedback from other users. I know that A:M folk occasionally pop by to see what sort of progress you're making, and I'm sure other people with experience with other Animation systems have opinions as well. After all, the more feedback you get at this point, the more mistakes you can avoid in the design! :P


OK, I'll jump in :)

Ive been monitoring this thread, and to be honest, both of you have good ideas about how a rig should be. In some circumstances, one would work, in other the other would work. Why not add a global option to switch between these 2 ideas with connectors and 0 DOF's.

Of couse, that would mean more work for sascha ;)
Squirrel Havoc

We live as we think, very very slowly....
squirrelhavoc
 
Posts: 180
Joined: Tue Jun 28, 2005 11:17 pm
Location: Oklahoma, USA

PreviousNext

Return to General discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron