robcat2075

If I had to budget myself to one suggestion it would be that the head can not pivot around on the top of the neck like a gymbal. the head is the last link in a flexible chain that makes up the spine and it all has to come into play to look right. All those head nods and turns you are doing have potential, but the torso and neck need to be part of what is making that head move. It's even physically impossible to move the head without them doing at least a little bit. A mime might be able to isolate the head but in normal everyday action ti's all working together to create expression. There's lots of opportunity between the head and torso for overlapping action to loosen things up and create a more lifelike impression.

Bottom line, embedded or not embedded should not make a difference to a constraint. The only way i can imagine not-embedded models being a problem was if you created a constraint with some external models, saved the chor, then when you reopened it, some other models that happened to have the same names but not necessarily the exact same bones were being loaded instead. However i can't imagine how that situation would be created in the first place.

I know that for TWO we used chors exclusively with all models external and were still able to constrain things to other things.

All I know is that somehow my project worked. i don't actually remember how. rendering it to a black background with no alpha channel and compositing with some other transfer method such as luminosity might be useful. Applying a level adjustment could bring out the visibility of the smoke as needed.

extra credit fr the landing gear.

Happy Birthday to Gerry! Born during the Truman administration? Well, Give'em hell, Gerry!

The emitter is constrained to always point up regardless of how the cigarette is pointed. That allows me to use a fairly high viscosity setting on the particles so the smoke hangs in the air after it rises from the emitter.

3D animation might be the most difficult way to do a book trailer, probably why it's not widespread. Probably harder than writing the book.

1) i don't know. 2) I don't get that option, probably because i don't have an SSE4 CPU. SSE4 are extra CPU instructions that help the CPU plow through some data faster. I don't know of any downside so go for it. 3) Timelog? I hadn't noticed it.

There is no more "stuff" file for A:M There is a downloadable collection of assets and there was a link to it in one of the emails you got when you were buying A:M.

If you in the model window and choose NEW, the first three options are Decal, Rotoscope and Pose. "Rotoscope" does not appear in the list?

Placing Rotoscopes in the model and assigning them to standard views. PlacingRotoscopes.mov

Here, i got the fuzzy Iris to work with a spherical gradient. For a gradient to have a uniform fade the two rings need to be the same size, so the gradient is applied only to the two rings in the center of the Iris object and the rest outside of those circles is solid black. IrisOut.mov FuzzyIris.prj

Scratch the spherical gradient for the moment. Getting the transparency gradient to fade right is a problem. I suggest a transparency bit map instead.

I'm warning you kids... don't make Nancy come over there! If all else fails, do a Help>Reset all settings. (btw, this will lose all your custom keyboard shortcuts and other settings.)

A gradient will get you the same look and will be quicker to preview, IMO.

I thin that is the best solution, you could rig it with a pose slider to control the size of the opening. If you want a soft edge to the iris, a spherical gradient combiner could be applied to it.

Sorry , I thought the problem was that this one stopped working again. Looks like what you need to do is send the whole thing to Nancy, let her open it once, then you'll be good to go! None-the-less, it's good to hear you had success with your book trailer!

Here I am opening the unaltered PRJ and it works fine immediately... RustysConstraints.mov

Thanks Gerald! The temptation to get a 3D printer is enormous.

It's a curious circumstance. Everything was embedded in the PRJ you sent us but it worked as expected.

I swear all i did was open the PRJ you sent and then tried to find what was wrong but I never found what was wrong because it was working.

the torso targeting is the one that was clearly targeting the wrong thing. In TSM2 the torso control has no geometry solidly attached to it, it only influences the end of the spine

A fine horde!

- if they were the same rig then you could just reuse the animation from one on the other without having to use any constraints. -It's really clear to me that even when the constraints are working, the wrong bone is being targeted. Are we sure that that is not what you are seeing and not a failure of the constraints?