Hi I tried to build the Cosman Foot from Rigging01, but failed desperately.
The expression seems to be broken. I tried the origianl scene from Joe and that seems to be broken, too. Whenever I try to rotate the ArchR in Heading it snaps to a weird position and rotates from there. But rotations seems to be ok as soon as I switch the expression off.
Oh, using Studio 2.1a Pro.
One thing I donât know yet, too. I placed all my bones in local coord sys, but Joe seems to use world coord sys (at least sometimes). Is rigging in local coord sys a bad thing? When to use what?
Make sure you are in local rotations. ie click the âcoordinateâ button on the bottom right of the viewport to off or opposite of what you have now.
I fixed it with the help of Thomas. I have to be in Parent coord sys to make it working. The strange thing is that everything works fine until one adds the expression. From that point on it behaves weird in all coord spaced despite Parent. :shrug:
The problem with the rig you sent me is clearly a bug with the new Editsphere behavior (aligning itself to the selected coord sys). Be sure to send it to pmG.
Is rigging in local coord sys a bad thing? When to use what?
Basically it is equal what coord sys you use âŠ
BUT âŠ
You normally want to have the âcleanestâ possible rotation (no weird numbers on all axes).
To achieve that, you should use âParentâ coordinates whenever possible, since that is what messiah uses always for internal coordinate representation. The cause for this is, that it is the only possible coord sys for animation - for FK, you need the children to follow the parents when they are moved or rotated. Only âParentâ allows that without trouble.
But no rule without exception: âLocalâ coords are sometimes extremely helpful and much more intuitive for rigging since the axis is aligned to the actual object you rotate.
So the rule of thumb is:
Use âParentâ coords whenever possible.
Keep all three angles as close as possible to Zero.
In complicated situations, use whatever coords fit you, but keep an eye on the rotation values. If those go crazy, you may get problems with animation and weird interpolation.
It becomes even worse when I want to apply the expressions to my character. The arms are not modeled in a 90° to the floor pose but a bit more down. Now try to get to match the rotations from a null (which in parent space (the world) always points in the same direction) to my slightly âpitchedâ down hand. :banghead: Sure you can rotate the null in local space to line up with the hand, but the expressions donât work in local space. :banghead:
And it it kind of tendious to always make a parent null that you align up to have a child null that plays nicely.
Donât play with fire. Always rig in âParentâ coordinates ! Use ParentInPlace if you want to keep alignments and stuffâŠ
Itâs better to have the character nicely lined up along the axis but in the end, it doesnât matter.
Thatâs rigging my friend. Make sure FROM THE START that you control your orientations (eg with arms and legs heading is sideways, pitching is fwd/bwd). Thats why I hate all that Autorig stuff. It looks easy but orientation problems will get u afterwards. Donât hesitate to add some nulls to have correct orientations. Avoid gimble locking (when pitch=90, banking and heading are the same. You lose one rot axis) by adding orientation nulls.
Keep in mind that you may want to align (eg head, wrists and ankles) to other coordinate axis later on. Make sure everything is oriented correctly before u use the align expressions.
All this will result in a better, easier, more logical and comprehensive rig. The animator(s) will thank you for that. (Or better they wonât bother you with rotation issues)
Always THINK parent cooz. Use Local/World/Screen axis for animation only for it may be easier in some cases. Translating is never a problem. But if you rotate, check your graph editor EACH TIME you create a key. Weird things could have happened to the rotations (H/B +/-180). Correct those anomalies ON THE SPOT. It WILL avoid headaches afterwards.
In such cases it is always a good idea to have an additional null (or XForm null, as some might call it) as a parent to your expression driven item, to zero out its rotation. This means, use the âXFormâ null to rotate your hand into position (in setup) and have your actual wrist null parented to it without any rotation/translation. This is a rule of thumb in messiah (as long as we canât freeze, or zero out an items channels) whenever you are in such situations, especially when working with expressions.
Yes, the rigger does some tedious stuff to make things easier for the animator. Usually the time you need for rigging is much shorter than the time for animation, so every problem you can solve in the rig is worth the effort. And it will lead to a better animation with more natural motion.
If you look at my old rigging articles in the âDigital Productionâ we were talking about yesterday, I was using an immense amount of compensating null objects at that time.
I think I would reduce that today and keep things a bit more simple and straight forward, but most of the ideas are still valid.
Just forget the reverse foot setup I have used there - Joe Cosman has made my approach look superidiotic - Kudos to the master :bowdown:
I donât remember so well, but I think I had a similar problem when I follow Cosmans tutorials, and I think the solution was to turn on the old coord system, cause itâs an âoldâ rigâŠ
Thatâs why it would be good for messiah to have a FreezeTransformation function as in Maya!
While Iâm not questioning the need for a FreezeTransform, that would not be a good solution in this case.
Iâve helped Alex with this and it turned out there are two problems with the setup. The first is the orientation of the bones.
When rotating objects/bones into setup positions, always rotate on heading, then pitch. If the object is to be headed in the opposite quadrant, and you rotate on pitch first, you will most likely rotate past ±90[size=2]°. Rotating on pitch past 90° will almost certainly yeild problems when the object is animated. However, if you rotate on heading first, you will not have to rotate past 90° on pitch. Again:[/size]
[size=2][/size]
[size=2]Always rotate on heading THEN pitch.[/size]
[size=2][/size]
[size=2]If you follow that rule, all coordinate systems will perform as expected. From this, if you experience problems in the various coordinate systems, double-check your setup pitch values on the object youâre experiencing problems.[/size]
[size=2][/size]
[size=2][/size]
[size=2]Secondly, the expression was wrong in Alexâs scene. In the reverse foot portion, he was applying the heading of the arch directly to the heading of the toe bone:[/size]
⊠to rotate the toe in the opposite direction 180°. As an added âfeatureâ, setting the channel operator to + will allow for additional control since the toe bone could still be rotated, as needed.
One last note on the rotation order:
If you find that you need to setup an object past ±90° on pitch, you should use a parent null to provide that orientation. The most common place for this will be in the root for legs, spine, or other veritcally oriented structures.
Yes, Lyle is right. Sorry I didnât answer right away Lyle. I was a bit swamped with work. :sad:
The expression was kind of working, but with the wrong setup. But I made another error when reproducing Lyleâs setup method. I didnât remember the fact that Messiah calculated with radians internally and I just substracted 180 from my channel value. That gave me very strange results obviously. :banghead:
So listen to the things Lyle said above and always remember to convert your channels with DTOR before you do any math on them.
The manual rotation order solution, will it be implemented internally in messiah soon?
When i use realtime add or realtime modify, does it then rotate in the right order?
For the most part the users of messiah are artist not programmers so when a workaround turns up it would be implemented in messiah asap or least be written in the manual.
Because all workarounds are not workflow for me.
heading then pitching⊠??? This must come out of the mouth of a developer. :rolleyes:
Well, certainly not an animator. Try freestyle animating and using 1st the heading and then pitching. Itâs impossible to keep up. To animate you need to do whatever you need to do. Keeping track of the axisâ ??? :argh:
Altough it doesnât seem much, itâs a little too much to ask, honestly.
ljilekor, youâre having a particulary bad day, arenât you?
I, the developer, am giving you insight into the requirements of the software to get around a problem, in this instance. Iâm communicating directly with you not to make your life difficult, but to give you solutions and to help us find solutions to problems. However, you are not required to use the information youâre getting from me, feel free to use info provided by other users. Those solutions will work, too. Note that the information I posted is to help you get around the problem until we are able to find a solution, and itâs good form in any software.
Also, keep in mind that my info was for setup not for animation. In animation, objects must follow the motion desired by the animator, but a setup will either make the animatorâs job easier or harder. The info I provided was intended to make it easier.
Are you requesting the ability to change rotation order per-object? If so, this sort of thing wouldnât be implemented in a maintenance update. It would require a major change that would require significant testing. It is possible that you will see this feature in a major upgrade, however, it will not be available in any of the forthcoming maintanence updates.
Yes, however, you should be careful to avoid creating any âjointsâ that exceed a 90Âș angle.
Understood. However, picking up some of the basic tech knowledge is a good thing. The majority of problems that are encountered in doing setups can be solved by gathering some basic setup procedures.
Many softwares try to minimize the problems encountered by the âless technically orientedâ by adding additional fixes that must also be âlearnedâ by the user. And these fixes are themselves prone to need fixes. What you end up with is software that appears to be more complex (maybe even bloated).
Weâd like to avoid this as much as possible by creating more transparent solutions. And as we create them, weâll post more info. In the meantime, donât allow yourself to be intimidated by the provided info. Try it; itâs not as difficult as it sounds.
I canât agree enough with this. Since my day job consists of developing custom apps and integrating off-the-shelf solutions in a corporate environment and then doing cg and motion graphics by night I get plenty of chances to see things from both sides of the coin.
To a certain degree an end-user must be willing to take the time to adapt to an applicationâs workflow in order to get the most out of the tool. But at the same time the functionality exposed by that workflow must be rock-solid or the tool will be useless. Tacking on fix upon fix (or feature upon feature if you are in marketing) invariably only serves to further clutter and obfuscate the end-userâs workspace and at the same time introduces more maintenance headaches and places for bugs to pop up for the developer. The end result is that both parties end up more frustrated than before.
Iâve had to integrate enterprise software whose interfaces were atrocious because of all the added features that were tacked on over the years. Eventually the workflow is destroyed because features that logically should be coupled with other features end up being crammed somewhere else because there is no room left in the spot where they should go. Iâve wasted countless hours debugging my code because my project manager made me throw in a feature some VP requested on a whimsy that would only get used once yet introduced 10 new side effects to the code.
The great thing about Messiah is that it has robust expression and scripting capabilities that enable the end-user to accomplish so much. Any seasoned artist knows that there is no separation between the art they create and the technical aspects employed to create it. For a painter there is intimate knowledge of brush fibers, paint ingredients, and canvas grains. A puppeteer must understand the balance and counter-balance of his rig. A guitarist must know how to string and tune his instrument. Itâs no different for the CG artist. Software should only seek to shield a newbie from its details for so long, otherwise it becomes an impediment. And if an end-user wants to become an expert they have to be willing to forgoe the canned effects and use the real power of the software to build their own solutions.
YikesâŠI truly did not mean to bring this thread to such a philosophical level. I think itâs because my team lead and I were venting about the idiocy of our unqualified managers and the decisions they force upon us. Please forgiveâŠ
No offense, lyle. I may sometimes go too far but donât feel attakt. I think messiahâs great.
Weâre just used to diss eachother a lot at home(Were great Dave Chapelle, Eddie Griffin,⊠fans). Couldnât help myself being a little sarcastic there. :twisted:
Just want to make messiah as accesible as possible. The animation artists donât like too much âoâ that technical stuff. Somebody with a basic knowledge of 3D should be able to open messiah for the 1st time, rig his character and pull of a good animation. All this within one day.
In this philosophy, Iâm working on a hardcoded rig. Just want to push it a little further than autoRig. Have some âideasâ. Be happy to share them with you (lyle). But I need some help on a few issuesâŠ
