raillard
-
Posts
95 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by raillard
-
-
I did my testing in v13.0q...anyone see any major problems with these on their system?
Hello, David.
I downloaded your zipped files, and tested your arm rig in v13.0n. As expected, everything worked fine. I saved the action file and the model in a project file, and then I reinstalled v13.0q, and then I reopened the project. I got the same periodic drift that Robert Holmen documented on the initial post of this thread. Everytime I toggled the pose to FK, the hand jumped by an annoying degree.
And then, suddenly, it began working flawlessly.
What did I do? I have no idea. Now I can't make it misbehave. I tried your leg file, and I cannot get it to make the precessive jumps. The perfomance is rock solid. That's good ... I guess. I wish it hadn't done it with the arm, on my initial try, zo.
My own rig is more constant in its flaws.
I'll still be using using n until r comes along.Sincerely,
Carl Raillard
-
I haven't tried going back to 13h yet, but I'm wondering... If different versions interpret the same switch differently, what will happen at render time when the animations are all rendered in a different version than they were animated in?
Hello, Rob.
To the best of my understanding, they should render fine. The latest versions of AM (version v13.0o, onwards) are having difficulty creating keyframes when the constraints are set to 0%. This is what happens inside those IK/FK poses. If you use a version of AM where this feature is functioning, those keyframes shall be created in the proper way. If, after you do this, you open the project file in a later version of AM, those good keyframes shall still be there, and things should work fine.
If this problem were not so critical, it wouldn' be worth talking about, because the guys at Hash are busy working on it (source: Noel). I fully expect version r to come out, soon. I'd be surprised if the problem isn't rectified, soon. However, this really is a critical feature, by now. Going back to version h or n is more productive than waiting.
I'd be curious to know if going back to v13.0n solves the Scarecrow's problems. David Simmons suspects the problem lies with the rig? He could be right ... and yet the fact that I'm having similar problems with a different rig suggests, to me, that the problem might lie in the program.
It's amazing how the ability to switch from IK to FK in a seamless manner has become part of my workflow. Now that I've got it, I can't live without it!
Sincerely,
Carl Raillard
-
There isn't an installer for the Oz disc though.
Hello, Paul.
Version n is pretty robust with IK/FK switches, too. That's the latest version where keyframes are reliably added when constraints are set to 0%.
http://www.hash.com/forums/index.php?showtopic=24979
There's an OZ version of this one.
Sincerely,
Carl Raillard
-
I have turned on IK/FK on frame 1 for all the actors. All the posing was done with this turned on and I witnessed alot of jumping around on Scarecrows left arm when I adjusted his right arm and visa-versa. I don't know if this throws the placement out yet or if there is a screen refresh issue after the jump that prevents me from seeing where the arms have actually been placed. I know that if I scrub back and forth after a jump the arms are not where they appeared to jump to. I think I will try to capture this with CamStudio.
Hello.
You might want to try reloading AMv13.0n or, if that doesn't work, AMv13.0h. In AMv13.0q the FK/IK switch poses do not create keyframes like they are supposed to. Robert Holmen noticed this, too.
I've reported the problem.
Sincerely,
Carl Raillard
-
Hello.
I did some further tests. I'm finding problems with my own rig, with IK/FK switching. In hindsight I see that Robert Holmen is correct, but I don't think this is a problem limited to the Scarecrow. I'm not even using the squetch rig, and I'm experiencing similiar issues. I've filed a report.
Robert, if this IK/FK drift glitch is seriously hampering your productivity, you might want to consider reverting back to AMv13.0h for the duration of this animating task. For me version h is one of the "sweet" ones. If you do go back to version h, and if that cures the problem, could you add a note to the comments section my report? ID 0004177. I think it'd be useful for the guys at Hash to know, to help zero in on this sucker.
Thanks,
Carl Raillard
-
It happens in any switch from FK to IK. In the movie I repeated it just to make it clear.
Hello.
Mtpeak is right. In the movie you posted, the drift does not occur at the initial switch. Or, if it's there, it is very hard to see. I've attached a jpg.
I use a different rig (my own). I chord the limbs of my chracters, so that the arms are perfectly straight out, and the legs are perfectly straight down. I also use the Bob Croucher/Mike Fitz constraint switching properties A LOT. In my experience, drifting is liable to occur if I repeatedly click the pose on and off. If I do it just once per fresh frame, the problem is not an issue.
Sincerely,
Carl Raillard
-
Carl, trying to open your project causes the following exceptions:
004, 004, 004, 001 and then A:M 13o closes.
Hello, Paul.
It loads fine on my machine.
I've attached a fresh copy, below. Maybe this one will work for you?
If it still doesn't, try clicking on it. On the webpage that appears, select all the text, and copy it all. Close the webpage.
On your computer, open Notepad and create a new text document (file extension .txt) and then paste the text in. Then save the Notepad document. Finally, rename the document, changing the extension .txt to .prj
Whenever I have trouble with a shared A:M document, this procedure usually works.
If it still doesn't work, you have two options:
1. File a report to A:M.
2. Admit to yourself that you don't really need to see this project, and that I am right.
By the way, I cannot claim to have invented the technique of using a null to spin a model, by attaching the model to the null via constraints. Jeff Lew covers this technique in his tutorial DVD. I'm pretty sure this is the industry standard, the way most animators make their 3D characters rotate.
Sincerely,
Carl Raillard
-
Any object that is moved only on one axis and is rotated on that axis will work fine...the problem is that when you've been animating a character in a Choreography, it could end up anywhere. If, for instance, the character were at -30, 0, -30 (X, Y, Z) in relation to the model bone (0, 0, 0), then using the model bone for the rotation would not give you the same results. In that kind of instance, it would be better to use something other than the model/Everything bone.
Hello, David Simmons. Apparently you and I are the only ones still interested in this. David Higgens has gone on to more productive things.
That's okayI've attached a revised project file. I deleted the constraints. On frame 24 I made my proxy model take a step forward, roughly 70 cm in the Z-axis. So now the character is roughly -80, 0, 70 (X, Y, Z) in relation to the model bone (0, 0, 0).
That's comparable to your suggested move of -30, 0, -30 (X, Y, Z) in relation to the model bone (0, 0, 0). Am I right?
To make things really torturous, I also rotated AND translated the model bone, pecking in numerous keyframes, in order to make the character face the other direction. This, in a nutshell, is about as torturous a manuever as an animator is likely to inflict on his model. Not only is the character offset from his model bone, but the model bone itself has been translated and rotated. This is a microcosm of the worst-case-scenario.
On frame 30 I translate the null 70 cm in the Z axis, so that it still floats over the character's head. Finally, on frame 30 I reapplied the constraints onto the model bone, dabbing the eyedroppers onto the null. The null rotates as before.
You can see for yourself how the character spins around just like before. He's doing it backwards. He's doing it 70 cm further into the Z-axis. But he's still spinning around, obediently.
Am I still seeing things goofy?
To me Animation Master is working flawlessly. This is just what I want it to do. No matter how the model moves in relation to his model bone, no matter how the model bone moves in relation to the origin of the Choreography, the moment I slap a Translate To & an Orient Like constraint (with compensate mode) onto my character's model bone, the dabbed target become the orgin of all future translations and rotations for my character. I cannot see an exception to this. This is a good workflow: Use constraints to hijack the model bone (or the Everything bone) if you want a character to spin en masse. If the animator has already begun to roll and move the character in the Cho, creating lots of keyframes in an effort to create a spinning movement, and if he then applies constraints with a half-hearted hope of refining the character's movements, that would cause a pantload of unforseen difficulties. That's the only exception I can think of. David, is that what you're talking about? If so, I must agree with you. The application of constraints cannot retroactively correct bad animation.
Thanks for the kind word about my rig. There was a glitch with it, but yesterday Bob Croucher found a good workaround. It was a small issue, but quite critical for what I want to do with this rig. I've now switched to v13.0o.
Sincerely,
Carl Raillard
-
I think Paul is correct here, Carl...unless I'm missing something, which is always possible. What he is saying is that once you move the character, it is no longer centered on the model bone. If you are using the model bone for the rotation, that bone will be rotating around the null/COG...so, the model will not be rotating as intended.
Well, gee whiz. Maybe I just don't understand the squetch rig. Maybe we're talking cross-purposes? Or maybe an issue has crept into A:M which needs to be addressed. I'm using version 13.0 h.
I've attached project file with a proxy model with my own rig, which shows how it's possible to rotate an entire character, en masse, using an offset null. I've attached a mov file too. On frame 24 the character takes a step to the right, leaving behind his model bone. On frame 30 he reaches up to a null, which pops into view over his head. Also on frame 30 I slapped a couple of constraints onto the character's model bone; I dabbed the eyedropper onto the null using Compensate mode. On frame 60 I rotated the character by means of the null. I used the above-mentioned recipe to switch to Eular mathematics, for easy spinning. Notice how the model bone goes flying up and around, rotating with the null? The null is now the model's center of rotation.
I'd be very surprised if the squetch rig could not do this. We're probably talking cross-purposes!
Sincerely,
Carl Raillard
-
Not a bug. All hip and foot control boxes seem to do that. Maybe we're supposed to turn something ON?
Hello, Dhar.
I think you're touching on something else, a different problem from what David is wrestling with. Nulls -- or what you call control boxes -- have a sort of flippy default behavior when you adjust their rotations onscreen, in realtime. I don't believe this is a problem with the program, however. For the animator busy adjusting things on screen, Nulls have always behaved slightly different from bones. The default behavior of nulls is to translate, for instance. You have to park your cursor at the end of the null to rotate it. For bones, it's just the opposite; the default behavior is to rotate, and you have to park the cursor over the bone's origin to translate it.
If you're rotating a null and you don't want it to flip around in the Z-axis, just hold down the Control key on your keyboard. That will elminate flippy rotational behavior, with both nulls and bones. By now I do this almost without thinking!
Sincerely,
Carl Raillard
-
create a new null, and position it in the Strawman's center of gravity. Apply a pair of constraints (Translate To and Orient Like) to the model bone
As you are using compensate mode, and the hips and other bones have already been animated away from the model bone, won't this cause the model bone to remain at it's location and so cause the model to rotate about that point insead of the centre of Scarecrow's mass?Be sure to use Compensate mode!------------------------
Short answer: No.
Long answer: The model bone will not remain in its location. The two constraints make the model bone (and, hence, the entire model) a slave of the null. The model will obediently rotate around the null. The model will move when you translate the null, too. Applying the constraints with the Compensate mode button toggled on ensures that the model doesn't snap into a unwanted position. It's the Mister Rogers button. You press it when you want to reassure the model: "I like you just the way you are."
I'm assuming David is rotating the scarecrow in a Choreography, and that the null is a separate object (not part of the scarecrow model). In the version of A:M that I'm using (version 13.0h), constraints can be applied to the model bone in an Action file, but the eyedropper doesn't work, so there's no way of tying the model to Action Object. I don't know whether this is a bug or not. I'm not going to report it, because in my models all bones are children of an "Everything" bone, which I use in lieu of the model bone. Does the Squetch rig have a root bone of this sort? If it does, you can make the character spin around in an Action file, using a null dragged in as an Action object. Otherwise David should do this spinning stuff in a Cho.
Sincerely,
Carl Raillard
-
I'm trying to animate an end over end roll of Strawman but as it goes past the 90 degree mark it starts to 'roll' at 90 degrees to the plane I'm trying to roll it in. I tried constraining it to a Null and roll the null but the same result. Is this a bug or am I mising something? I should point out that I am attempting to 'roll' it off it's axis (ie from the CoG of Strawman) so using the Model bone only means rolls as well as translations.
Hello.
It sounds to me like you're fighting a Quaternion interpolation. By default, A:M uses Quaternion mathematics to mimic natural-looking body limb rotations. However, for some applications (e.g. spinning gears) Eular interpolation is preferable. A character rolling end over end would be better served with Eular mathematics.
Here's a recipe you might want to try:
As you did before, create a new null, and position it in the Strawman's center of gravity. Apply a pair of constraints (Translate To and Orient Like) to the model bone, and dab the eyedroppers onto the null. Be sure to use Compensate mode! Then advance several frames and rotate the null. In the PWS, crack open the null's disclosure triangle. Then crack open its Transform disclosure triangle. The right-click (or Mac equal) on the Rotate field, and select Convert Driver to / Eular from the flyout menus. Now the program will use Eular mathematics to calculate the null's rotation. You should be able to type "360" in any axis, and the model will make a complete rotation. If you don't monkey with the other axis, you should get a nice, smooth spinning performance. The null won't try to buck you off when you get to the 90 degree mark, in other words.
Sincerely,
Carl Raillard
-
Hello.
Drag and drop poses have been reintroduced to A:M. I think it'd be best to create rotational keys for behavior, such as natural-looking hand cups, inside a "Helpful Initial Pose." As a matter of routine the animator should drag and drop this helpful pose onto the first frame of his Action file, or the first frame of the primary Choreography Action. (Boilerplate Reminder: Before you drag and drop, make sure the key rotations and key body buttons on the frame toolbar are toggled ON.) This Helpful Intitial Pose could be stored in the Key Groups folder, on the top of the list. This would be a natural place to store it. I think Bob Croucher wants you guys to drag and drop poses with keys activated on them, instead of using David Seymour's original constraint-heavy Key Groups idea.
I don't think messing with thumb bones inside the rig is a wise idea. Models are made with the hands flat for the sake of the riggers. Having the digits lay in a flat plane can help the job of laying in bones, and control bones, and control bones for the control bones, and control bones for the control bones of the control bones, etc.
It is very easy to go insane when rigging hands. Steve Cleary's hand gizmo is brilliantly insane. The hand gizmo is the one part of the Squetch Rig that makes me jealous.
Another reason to use a drag and drop solution: After you've dropped the pose, the rotational data will be inside the Action file. The animator can do something about them if he doesn't like them. If he wants the hand to slap down, with all the digits perfectly straight, the info is right there, in his Action file, ready to be edited or deleted or whatever. If you store attractive body part rotations in an ON/OFF pose, the animator will have to remember where this arcane pose is, if he wants to shut them off. Alternatively the animator could undo the Pose rotation in his current Action file. Both of these solutions are crude.
Here's my thinking. It's great that we can lacquer layers and layers of keys on top of each other, by adding Action files on top of Action files, and Poses on top of Poses. With that power comes a danger, though. If you've got a dozen active poses with rotational keys telling a particular bone how it should rotate, who gets the final say? Can the animator govern the bone in the Action file anymore? To his dismay, the animator discovers that bone rotations are now a committee decision; the vote of his Action file is only one of many. Glitchy behavior can seep in, in this way. The program is actually working perfectly, but it looks like glitchy behavoir.
Action-blending is an art. It is best to use it sparingly. Yeah, I'm guilty of rhetorical exaggeration, here. I plead guilty.
My advice is: Don't even begin to "solve" modelling "problems" by creating ON/OFF poses, which in turn will nibble away at the authority of the animator. If initial rotational key data is located in an intuitive place (such as the first frame of the Action file) then the animator's authority is not undermined.
Sorry for the bloody long post.
Sincerely,
Carl Raillard
-
Nimmie's fingers are not updating with the Gizmo controls and I have to advance frames to see the change. I don't know if this is a bug in the rig or the software?
Hello.
I'm pretty sure Steve Cleary's hand gizmo uses Expressions. He told me he was going to use Expressions to refine the gizmo, back in 2003. Expressions are susceptible to screen refresh issues. I reported a similar problem back in July (Bug Report 0003465). In the interim, as Dave Simmons mentioned, you can continue working by keeping a thumb on the spacebar, to manually refresh the screen, right after you adjust the gizmo.
Sincerely,
Carl Raillard
PS: Don't be ashamed of your animations. I think it's a fine thing that you are actually using the program. It's a great program.
-
Hello.
A lovely model is just getting lovlier.
I think a puff of additional specularity on her cheekbones would be nice. The nose looks perfect.
Nancy's suggestion about a hint of a smoky eyeshadow is an excellent one.
If I stand a yard away from my monitor, it's hard for me to perceive what she is looking at. Her line of sight doesn't jump out at me. The value of her iris is too close to the value of her eye-whites. Increasing the ambience of her eye-whites would cure that. Stephen Millingen did that with his Schlitzy the Dwarf animation. Blue-eyed characters benefit from exceptionally bright whites.
Sincerely,
Carl Raillard
-
... Is there a different constraint that would work better for this or can the action be started before time 0 in the chor?
Hello.
In the Timeline hit "M" to evoke the Move manipulator (the little hand) and then shove the 0 keyframe over to your right. You'll enter a negative realm, before the Choreography officially begins. Go as far back as your tardiest lag setting, and move the main control bone at that point.
This is a fairly recent feature, this ability to animate prior to frame 0.
I'm assuming you're working with v13.
Sincerely,
Carl Raillard
-
The darker eyebrows also probably work better for animation as well - facial expressions will be easier to read from a distance, even tho I think the blonder eyebrows are more interesting.
Hello.
I was just about to raise that point. I even made a jpg. I think this is what Robcat was concerned about.
Here's an idea: Have the blonde pigment adjustable with a pose slider. Crank it up for closeups, grind it down for long shots. If done with care, I doubt anybody will notice the color change; they'd just assume the lighting was skillfully tailored for the shot. In that way you'd maintain the unique charm of a distinctive pale-haired character in closeups, and yet he'd still be expressive when seen far away.
Respectfully,
Carl Raillard
-
Hi, Stephen!
Oh, that was definately worth the wait!
I want to see more! Quite frankly I'm more interested in your stuff, than I am in anything that Hollywood or Pixar has planned. Sad but true.
I love how Briar skewers the apple. Is that Mosey as cupid?
Sincerely,
Carl Raillard
-
Hello.
I took a look at your models in my copy of A:M v13.0e.
I had no problem examining your models. Two things caught my eye, zo.
Firstly: Both models have an item called "Drivers" embedded in them. This is listed just below the Splines folder, inside the Model, in the Project Workspace. I would advise you to delete these Drivers things. That might help. I don't know what they are, but I don't think they are healthy inside a Model. (Drivers are supposed to be inside Actions -- they are the splines that define movement.)
Secondly, there is something a bit odd about the mesh of the soles of your character's feet. They are grouped together (in the Groups folder) and the surface color is dark blue. That's fine. What's odd is that their surface transparency has been set to 100% so they don't render. Is that intentional? If it is not intentional, then you should crack open the group's disclosure triangle, crack open the Surface disclosure triangle, right-click on the Transparency setting and choose "Not Set." This might cure your problems. I'm thinking perhaps your graphics card is having difficulty rendering these transparent groups in realtime. If you want your character to be running around on invisible soles, then your next step should be to update the video drivers for your graphics card. Animation Master runs much more smoothly on machines that have up-to-date video drivers.
Respectfully,
Carl Raillard
PS: The reason the Standard Manipulator does not appear on the Head bone is because, inside the model file, the Head bone has its Limit Manipulators set to ON. This bone is specified to rotate only.
-
Howdy.
Everything that is reflective in this movie (and there seems to be a lot of tin!) is in danger of getting lost. Every piece of metal is a potential chameleon. I think the metallic texture looks swell, and the Parrish-style lighting is very good. But the sky really needs to be brightened, with some additional atmospheric haze, to make the castle walls visible again.
I've doctored one of the images to show what I mean. Essentially, wherever there's an important metal edge, what is behind has to be different from what's in front. This can be either a color difference (from warm to cool) or a brightness difference, or a combination of the two. But it has to be different.
Maybe it'd be possible to use a fog limited to just the sky dome, or use some trick with Composite & Post Effects. I'm not conversant with these new tools. That's my cue to go back to lurking.
Sincerely,
Carl Raillard
PS: Oh, the trees! Maxfield Parrish had difficulty with trees, too! What strikes my eyes is: The dark areas of the trees ought to be brighter. Keep it high key. Foliage should not call attention to itself with a lot of dark darks next to bright brights.
-
Hello again.
Thank you, Marcel. Zevel works like a charm, now!
I just tried out my copy of PuZh plugin, too. I am happy to report no problems. It's just what I needed.
http://www.kci-group.com/z/puzh.htm
It's swell! Ha ha!
Sincerely,
Carl Raillard
-
Hello.
Is the Zevel plugin, which adds a bevel to splines, supposed to work in Animation:Master version 13?
I downloaded the plugin here: http://www.kci-group.com/z/zevel.htm
I installed it into my htx directory, and then I tried selecting a single CP along a donut, like the example shows, but it always crashes the program.
I just ordered the Puzh plugin. I hope that one works!
Sincerely,
Carl Raillard
-
Well, I have never learned the silhouette rules
Hi again.
There's only one rule. A gif is worth a thousand words, so I've attached one. The minute you see it, I'll bet you'll recognize it.
One downside to a religious observance of the silhouette rule is that it can lead to stagey performances. Every gesture becomes crystal clear and obvious (Dare I say it? Belabored). Similar to an over-reliance on "anticipation," the end result can strike the audience as hackneyed and insincere.
The way you've set up the scene right now, the replacement of the heart back into the chest is quiet and subtle ... and yet that might be entirely appropriate for the dramatic nature of the scene. Perhaps an overly-obvious gesture is the wrong thing to do, right here.
Perhaps I should go back to lurking.
Respectfully,
Carl Raillard
-
Enjoy and please comment... thanks!
Hello.
For silhouette rule reasons, you might wish to try putting the heart in his right hand (if continuity will allow this change). Maybe have his left hand close to his right hand, to suggest that he just transferred the heart from one to the other. The Tin Man's reflectivity is going to make him blend into the background a lot; observing the silhouette rule with this character will help make his actions clearer, methinks. Making the background slightly out-of-focus would help, too.
I'm busy testing a new rig for a proxy model I'm building. I thought I'd give a pass with your scene, with my model, just to show how the scene might play out with the heart in the right hand. You did the hard work, with the timing, thank you. I just slapped down different key poses with my proxy.
I'll leave it to others to give advice about mood, facial expressions, etc. since I haven't read the script and don't know what's going on!
Sincerely,
Carl Raillard
Steve's Head Gizmo V2
in Featured Rigs
Posted
Thanks, Steven! This looks really useful!
Sincerely,
Carl Raillard