[Troll, faerie fly-fishing...]

That's a shame - I think this would look really good in colour. Rich tones in the troll's skin texture, nice sparkly colours around the fairies, a nice golden sunset as the troll strolls home...

[Constraining two arms together]

Last year I had a similar problem. The approach I took was to constrain the axe to one hand and the other hand to the axe. Which hand takes which role is up to you, but I would constrain the axe to the hand that (in this scene) does the most work in moving the weight of the axe. This approach of course falls down if the scene requires each hand to, at some point, drive the axe's motion. I think it would be hard to give a sense of the Tinservant moving the axe around if you constrained both hands to the axe. YMMV.

[Troll, faerie fly-fishing...]

More and more I think he should stick with the current ending - anything else turns it into slapstick, or a gag, or similar. The atmosphere I was reading from the bulk of the storyboard (especially after re-reading) was more of delicate documentary - a visual equivalent of a musical etude. Given Will's artistic abilities, I think this will be visually stunning, and trying to add a big ending would detract from that.

[Troll, faerie fly-fishing...]

Awww...poor fairies! They actually get squired onto the hook? Sounds abit barbaric. .... I'd put them into a smaller cage on the end of the line with a hook at the end of the cage.

Nah! Seen too many cutesy-cutesy fairy tales - tell it like it really is!

How about abit of justice at the end ... I just think it needs more of a "hook" to it. A sort of punchline thing going on.

I was about to say that I agree with that, but I'm having second thoughts. Maybe because I can't think of a suitably punchy ending that doesn't involve a lot more work.

[Decaling]

Come to think of it, as the top plate obscures the key bases, there's no need to join all your keys together into one surface.

The key bases are not joined into one surface... that is the top plate...

My mistake - I misinterpreted your image.

... but figured I ought to rebuild and learn my lesson about saving to separate files...

Not only that, but get in the habit of taking extra back ups as you go. If you save your models to separate files you reduce the damage if a file gets corrupted, but you still lose the work in the corrupted file. If you take regular copies, you have something to go back to. Or rename your model every now and again (eg with a version code on the end that you can tweak).

[a silly question?]

...said it had about 174 minutes left.... (and I'm on DSL, shouldn't that be faster?). Then all of a sudden (about 3 minutes later), it was done!... Did I actually do something right..?

Don't panic! Your DSL connection only reaches as far as your local phone exchange, but the data you're downloading comes from several hops away (on links that are probably even faster, but are carrying everyone else's data transfers too). The download speed you get is (more or less) determined by the slowest link. The "XXX minutes left" is calculated from the rate at which data packets arrive, and early on in the process your computer doesn't really have enough data for an accurate prediction of completion time.

[Decaling]

... but the problem is those 45 + decals at 600 X600 pixels, one for each key. ... I have tried hiding all but the tops of all the keys and making a large decal of all the letters and numbers. It is not working because the model then will not stand up to scrutiny.

I would go for the one-decal-for-all-keys approach - but it will need a higher resolution than 600 pixels. To find out how big your image should be, you'll have to know how big (in pixels) each key will appear to be in the final render.

I can up the actual dpi resolution of the targa...

Forget about DPI. A:M ignores DPI (as not all image file formats contain a DPI value) - all it cares about is pixels.

 

After all that careful splining, I hate to suggest that your keys are more spline heavy than they need. You have three ring splines defining the base of each key. With careful tweaking of gamma and magniture values, you can easily get away with just one. Absolute accuracy isn't necessary here as you're covering up all that detail with the top plate. Come to think of it, as the top plate obscures the key bases, there's no need to join all your keys together into one surface.

[applying textures and decals]

A second unrelated question -- if I apply a decal that has "black" pixels in it (RGB = 0,0,0), then they get rendered as transparent. Is there anyway to turn the transparency off?

Getting the easy question out of the way first... There's a setting associated with each image (in the PWS's Image folder) called "Key Color". Right-click on that and select "Not Set". (Or select any other colour you would prefer to be transparent.) Images with alpha channels don't get this option as the alpha channel controls transparency.

[Can't Uninstall]

Last year I also had to delete the "/Library/Application Support/Hash/" folder (and its contents) by hand when uninstalling/reinstalling. (That's the Library folder at the root of your hard disc, not the Library folder in your user home area.)

[Booleans]

What's causing it to do this?

I'm guessing it's because of how I connect the CPs, I don't know how to do that properly.

I haven't looked at your file, but I'm assuming you've not used Booleans here.

 

Some of the splines that make up the heart are valid four-point patches. Some of the nearer patches are facing away from you and so are not being rendered, and some of the more distant patches are facing you and so are being rendered, which is why you're getting that "inside-out" look. (There's a setting in A:M that will make all back-facing patches show too.) What you need to do is add a few CPs that will make the heart patches invalid. For example, add an extra CP (not spline) to each of the verticals that run up the centre of the heart. This will create five-point patches of all the patches that use either of those verticals. So long as you don't explicitly tell those five-pointer to render, they will stay as holes. You'll probably have to add CPs to the other splines that reach across the face of the heart too.

 

It'll make sense when you do it!

[hero model size limits or restrictions.]

...and the stereo settings too.

[hero model size limits or restrictions.]

For a character of typically humanoid scale, I find it best to model it 1:1 - if your character is six feet tall, model him six feet tall. Unless there are very good reasons, I don't see any point in doing otherwise.

 

A few months ago I started modelling a humanoid, but only about six inches tall rather than six feet. I did this simply because it matched the default import size of the rotoscope I was using as a guide. Trying to judge proportion and real life comparisons (e.g. my own body) was much simplified when I scaled it (the model, not my body!) up to full size as then I didn't have to use conversion factors.

[create a 4 point patch?]

From a so called 'master' I expect a different answer than the childish 'I give the-sphere-trick to someone else'.

He wasn't giving it to someone else. He came to the same conclusion that I did, namely that if you're having a problem making a cube, you're not ready for the bigger problem of making a closed sphere.

The question was and is about the make-four-point-patch.

So why did you ask about spheres?

 

I suggest you take Martin's advice and go through the tutorials - you'll get more respect from the rest of us as you'll then have a better idea of how A:M works.

[Golden Gate Bridge High Detail model]

I guess action objects are treated differently than when you are manipulating the base model. As you can see in the attached image, the model I brought into the action has both groups with materials and decals but none of that is exposed as a fully expanded instance of an action object.

... Can you drop poses on action objects?

If the object you're using as an Action Object has a pose, that pose can be adjusted within the action, but not in the chor (well, not directly). You can also apply constraints to the Action Object's bones. I've used this approach on a generic piston I used as an Action Object: I adjusted the piston diameter via a pose, and then constrained the piston's base and plunger bones to bones in the action's target object. At a later stage I intend using poses to control 'animated' grunge maps, so in the action I can select one of several grunge maps. Hey presto, one model looks different in each instance.

[Old Film Noir Art]

These are very nice, particularly the first two. Exceedingly minor gripes about the first image: (1) the chest seems a bit too well-developed, and (2) the letter in the foreground doesn't help. Either make it grubbier (so it's not so obvious) or remove it (which would add to the mystery of the image). The silhouette could very well be taken from a photo of a real person, so it's similarity to the guy in the first image suggests you haven't cheated - very nice!!

 

BTW How much Photoshopping did you do? If you could replicate the first image in A:M, but animated - something simple, like the man looking around, or getting up and walking out of shot - I think it would be fabulous.

[Decals defaulting to smears...]

I've not seen this before. Do you get the same results in a final render-to-file? It's hard to see exactly what's wrong with the image you posted, but I'm wondering if maybe your decal tiling repeat value (I'm assuming you've repeated your image along the side of your tank) has gone haywire.

[3 Segment Live Action Shot]

2. Any suggestions on how to "dirty the vehicles" ?

Diffuse maps! Find yourself a nice greyscale grunge map and apply it to whatever parts of your model you want muddying up. For a quick and dirty but inaccurate grunge map, use the Filters->Render->Clouds filter in Photoshop (or PS Elements). For a more accurate diffuse map, you'll of course have to create your map to appropriately match the grungier parts of your models. It might be a good idea to also create a specular map (and reflection map if you wish) based on the diffuse map - that way the grungier parts of your models will be less bright and shiny than the cleaner parts.

[Getting the feet wet in A:M...]

STUART: I do realize that Tubs and Pepperbox do get a little lost in some shots. Everything should be considered provisional at the moment until ...

I realise this, which is why I said 'one day!

So...to that end, would you go ahead and explain Gradients Materials, also Light Lists.

The light lists is easy, as the link Mike provided shows. Try this: create a new, default choreography and drop a couple of objects into it, side by side (so they're both illuminated by the default lights). Do a quick render to see what it looks like. Now drag the key light's shortcut onto just one of the objects. Accept the default value in the dialogue box that appears. Render again and see that the object without a light list is not illuminated by the light you added to the other object's light list.

 

As for the gradient materials, I think I'll have to leave that to others. It's been a while since I last played with them, and I would like to try it out before saying more, but A:M is crashing every time I try modifying my gradient material. (And I'll be away from A:M for the rest of the weekend.) Sorry.

[Getting the feet wet in A:M...]

I kinda figured that if I declared the project, and posted it in the Showcase, it would serve to keep me moving along on it.

Damn right! With material like this, you're not going to get a moment's peace.

Here's a few more pics. of the street.

Again, very nice. Your troopers are getting lost amongst the detail of the background, so one day you should ask us about gradient materials - you can fake a nice rim light with them that will make your troopers stand out from the background quite nicely. Anyone who's seen Stephen Millingen's (pequod's) "Briar Rose 'entrance'" test anim will know what I'm taking about.

 

BTW I took a look at your website earlier - you have some very nice material there. I do hate it when people show how much more talented they are than me, which is why I hate everyone.

[Getting the feet wet in A:M...]

I do like your sets. They're very nicely detailed and textured. With some imaginative scripts, I reckon you could have some fun animated shorts with this stuff.

[Light aberration: not volumetric, not lens flare...]

Here' a diagram showing the alley, light & troops. [side View] The Kleig ... throws no shadow. There's a small, rather weak Bulb Light above the two troopers. It throws enough light to show that, in fact, their feet are off the ground.

There's something about the klieg's shape that makes me want to ask if you can check the settings of that klieg and make sure it's fall-off distance is actually long enough to reach to the ground.

Stuart: I had been moving the troopers up and down the alley to check how the light was falling on them. At the far end of the alley, there's a set of stone steps. Step#1 is a bit higher than the floor of the alley.

Fair enough - I thought it prudent to ask in case we were missing that "D'oh!" moment.

[Light aberration: not volumetric, not lens flare...]

Those troopers look like they're hovering. There are shadows on the ground directly under their feet. Or are these from different lights?

[Where do I go to post renderings of my work?]

For finished works, try AM:Stills for still images, and AM:Films for movies (although I've never managed to successfully upload to AM:Films).

[Light aberration: not volumetric, not lens flare...]

Shall I use 'light lists' to make these move along with the troopers? I was thinking of using a 'Translate To" Constraint with an offset. What do you think?

You will need to use "Translate To" constraints as well as light lists. A light list is simply a way of excluding things from being illuminated by particular lights - it doesn't physically attach the light to an object.

[Test Animation, trying to build a rig (AM Complete Guide)]

The knee targets will *pop* when extended fully and I think that's my problem. Here it is, enjoy.

It's a natural result of the relationship between knee angle and body/foot-target distance. A small change in foot-target gives a small change in knee angle when the body/foot-target distance is much less than its maximum, but it gives a relatively big change when the body/foot-target distance is near maximum. The trick is to keep that body/foot-target distance less than at full stretch - in your case not letting the body get so high before taking the feet off the ground (or taking the feet off the ground a little bit earlier). I find this quite a tricky feat. In my own (incomplete) rig I have separate IK and FK legs, so that for extended periods with the feet off the ground I can constrain the true legs to the FK legs (so the legs ride with the body), while constraining them to the IK legs for normal use.