robcat2075

Well, after about an hour and half it finished, but I can't find any new keyframes made. Is it even possible to bake hair on an object that only lives in in the chor as an action object, as the trees in Winkieville in TWO do?

I know that's a bit vague, but I've never baked hair before. I'm trying to bake the hair (tree leaves mostly) in that opening aerial shot in TWO. It's a big shot and it will take many minutes to compute the particles all the way to the last frame if I'm just scrubbing the timeline, but should baking the scene take much longer?

I don't think it's special. Now that V16 is released I think the limit is 4.

I think that only works for limited animation like Hannah Barbera did. The fact that they only staged their characters in certain ways made it semi plausible that so much of their motion would always look the same. Still, only kids mostly accepted the shortcuts. There are a few wildly successful properties like The Simpsons that can have things keep looking the same over and over and even use it as a joke, but they're not 3D. I think audiences' expectations for 3D are too big for that now.

that looks wonderful! You should start a new thread with the link at the top so people will find it easier.

Mark Skodacek figured this out. Thanks, Mark! It's a small matter of adding a few constraints to already existing relationships in TSM2. In the PWS>your model>Relationships>User Properties Relationships>1 right arm Relationships>1 right arm FK/IK Relationships... -edit "Relationship 1" (in some TSM2 models this may display as "Error Loading String: 50021") -add the following constraints to 1 right arm IK control -- Translate to... 1 right hand control. Change its enforcement curve to "Hold" interpolation, and set the curve values as to 100% at the start and 0% at the end. (the attached JPG shows this particular curve) -- Orient like... 1 right hand control. Change its enforcement curve to "Hold" interpolation, and set the curve values as to 100% at the start and 0% at the end. -add the following constraint to 1 right lower arm -- Kinematic Chain To... 1 right arm IK control. Change its enforcement curve to "Hold" interpolation. Leave its curve values as default with 0% at the start, 100% at the end. -add the following constraints to 1 right hand control -- Translate to... 1 right arm IK control. Change its enforcement curve to "Hold" interpolation. Leave its curve values as default. -- Orient like... 1 right arm IK control. Change its enforcement curve to "Hold" interpolation. Leave its curve values as default. close the Relationship 1 edit window Do the above maneuver for the left arm also. Save your character. (Do i need to tell you not to save over your original?) In my chor, when I'm using this alteration, I change the interpolation of the "right/left arm FK/IK channels" to "Hold". (These are found inthe "User Properties" folder for your model... in the chor) In regular TSM2 you could/needed to transition from IK to FK by making similar poses with each on successive frames. This is no longer necessary with seamless IK/FK and you should always set the "right/left arm FK/IK"slider to either 0% or 100% or it will not force the keys it needs to force for the process to work. Those keys are very important to prevent unexpected results on animation already keyed. When going from IK to FK I switch the slider to FK then back to IK then back to FK to make sure everything about both states of the arm is keyed in place. It takes all of three seconds. Vice versa when going from FK to IK. I used this addition to TSM2 on my Shaggy for my BUS STOP animation and it seemed to be quite robust and very helpful, but it is possible to create confusing results for some one who does not use it carefully. This new IK/FK addition will probably not be 100% compatible with animation you have done previously using TSM2. It is probably possible to incorporate these additions into a "model" that is imported into an existing TSM2 character although I haven't investigated this. I'm sure it's also possible to do a similar upgrade for the legs and I bet Mark will figure that out for us, too!

While researching I found this anti-Quaternion article: http://www.gamedev.net/page/resources/_/do...aternions-r1199 It's a lot of math i don't understand but most interesting is the Editor's note at the top disavowing it, in light of an apparent flame war revolving around it. The writer's apparent proposal to ditch both Euler and Quat for "Vector" interpolation may have merit... in my brief test in A:M it seems quite functional. I'll test further when i have some time.

It probably thought it was placed way to the side of the visible screen.

Hmmm.... I was able to vote again! It still had a few hours to go... well everyone vote just in case.

Ah! Now I can see. I like the face. If you were going to pursue rigging that my suggestion would to model him in a more neutral expression. Right now he's in one extreme and it will be tricky to get him to extremes on the other end. But it's good looking face.

It's a bit dark... but looks promising.

We'll need a mac user to chime in on this, i think.

I recall you need an actual extra copy of the A:M program for each instance you want to run on a Mac. You can't run that same A:M multiple times like you can on a PC? You've done the copy thing , right?

Jason@Hash would probably be your source of latest info.

Is this a Windows-only thing, because I cannot find any way to activate/deactivate multi-threading in the Macintosh version of 16. For the moment, it is Windows only. Steffen put up a note that he had to remove it from Mac because of a compiler(?) bug that prevents if from working in Mac. Most things we do with A:M didn't use MP anyway so you wont' notice the loss much. Particle simulations and "Finding patches" (lengthy on very large models) are the two major things that can be sped up by it currently.

I voted again. I encourage everyone to take a minute and vote for Gene! Although the lure of Yugoslavian rappers will difficult to overcome.

I saw them and wondered where the hell they came from. Then in the Reports section I saw you bug report. I have added a "monitor". TIP: when shift-selecting several bones for copy/pasting keys... Copy while the KeyBone filter is on and Paste with the KeyModel filter on. That prevents Bone Position Keys from being made.

But this is the same model I used in my other animation and it did not have the leg wobble (straight walk.) Maybe you crouched a bit lower or higher or lefter or righter than before. It's like a cliff, it's not a problem until you go too far. Why should I go back. Three dimensional space seems easier to understand. Also, if the W driver is to make things smoother, do I really need that for my machine? 3D space... you got that either way. But we're talking about angles. Quat will interpolate from angle to angle far better and more intuitively than Euler. You don't need to know what the W means. All anyone really does with those curves is look at them and ascertain whether they are changing as fast or as slow or as not-at-all as you want.

And I'll add again... you don't even have to try to be synched... just talk about something about your shot.

You deserved a break. OpenCl, that's some sort of GPU computing thing...that sounds like some new wonders are on the way.

btw, there are a bunch of "Bone Position" channels in your chor. These are caused by a bug in copy/paste. You can and will want to delete all those whenever they occur. For example, expand "Pelvis" to see some of them.

This is really a problem with the "knee" trying to "aim at" the knee target which is placed rather low. Flopping to the side was the "best" it could do given that the lower leg will prevent it from getting any closer. At the start of your scene, move the Left Knee Target up to about the level of the Pelvis bone. That seems to be a better overall place for the knee to try to point to without having to move sideways. Since legs and arms move quite a bit in animation, elbow and knee targets often have to be managed during an animation to get the best result. Go back to your Quat version. The only time you really need Euler is for things like propellers that need to spin more than 180°.

True. This is really the procedure for importing image sequences that have associated sound in to A:M for the purpose of using it in A:M's NLE functionality. Which I didn't think even worked at all until I found this workflow. Ultimately, A:M doesn't give you access to Quicktime's audio compression possibilities, so if you really want a nice Quicktime from your animation with sound I recommend either of the two methods I mentioned previously.

But what is in the unexpected pose? Expand it... what's in it?

Constrain the leg to the foot, not the foot to the leg. You're the one who made the poses, right? I dont' know what you were doing when you made them, but you do, right? What made you make an extra one? If you dont' recall , it's easy enough to open them in the PWS and look to see what's in them. What's in them? It should only require one pose to contain the IK constraints for the two legs.