robcat2075

Hey... I just got an idea for who you can recruit to program that FBX thing!

You fooled me... I thought those shadows were real! I'm not sure I understand your setup exactly but how about this... Instead of putting the tree image on the light, put it on a card in front of the lights (a transparency map) and arrange it so its shadow falls on the road and on the character: Shadows.mov When the same light is shadowing the character and the "trees" you'll get one proper shadow on the ground for both of them. Here's the PRJ of my simple example case: Double_shadow_problem.zip

there better be some monsters in this movie

If you want Bone A to copy the motion of Bone B without going to where Bone B is, you need an "orient Like " constraint. Does that help?

I guess what you want is to not have a shadow in a shadow, right? My first idea would be to paint out the shadow on the front projection image (or get a shot of the road where there isn't a shadow) and use your A:M lighting to recreate it so the characters shadow and the shadow on the road are the same shadow. Another possibility, that requires some compositing program, is to use a "darken" composite mode to combine the shadow layer and the road. Instead of adding the darkness of the shadow to the road it only darkens the road where it was lighter than the shadow. The shadow parts of the road don't get any darker. These are both tricky to do, but does that make sense?

Always use Lathing to make anything circular. It automatically adjusts the bias of every CP to make the circle round. Lathe out a few things with different lathe settings and click on a CP and look at its bias properties to see how the bias has been changed from the default 100%

In that case, Matt is correct, you can drag any bone in the PWS, even from one model to another, to re-order a heirarchy and it will take it's children with it.

In general if you need to move some set of bones together as a unit while in the bones window, select the bone that is the parent of the set (hope there is one!) and use the translate, rotate and scale manipulators to re position as needed. The children will translate, rotate and scale along with it.

As Fuchur noted, he has collected quite a bit of information useful to people wanting to use A:M to develop for games, but if you gather any further insights we'd love to have you share them here. Martin said that one of the most frequently asked questions about A:M is "Can I make a game with this?"

I know you have to save in an old ai format. version 8? I think it also needs to be a not filled shape? I've only used it rarely.

I wonder... if there's some way we could talk them into letting Steffen have the code for the plugin and do the conversion for them?

I've noticed that although A:M is much faster overall, procedural materials don't seem to have gained much. BTW, did you consider baking the darksim textures? That would have been faster.

Yeah, I notice it has trouble deciding which will float to the top.

A Boolean in A:M is a mesh that will cut a hole in another mesh. They must both have their own bone. The bone for the "cutter" should be a child of the bone for the mesh that will be cut and it must have "Boolean Cutter" ON. Both must be fairly closed shapes. It makes cuts and holes possible that would be ghastly horrors to try to do with splines. BUT... the cut only shows in Final renders. Boolean_Example.prj

Martin would say... it is what it is. From the beginning the goal of A:M hasn't been to access every possible means of CG production, but to provide useful tools for character animation and the pipeline for that from modeling to render. That's not dark to me, I'm glad I can do the whole project from start to finish in A:M and not need to translate assets. If you need something A:M doesn't do, then you need it and you have to decide if that thing is worth the loss of what you get with A:M. If it is, it is. That's a judgement you need to weigh. As you suspect, flawless translation of splines to polygons and back is a huge programming challenge. A:M has one developer now and he does a great job, but he has focused his time on things that benefit the most users overall: moving to 64 bit, a huge speed increase, upgrading NetRender (now included in A:M) and of course, reliability. Everyone benefits from those changes. Very few A:M users need to translate to other apps. None-the-less, there are several threads here showing how people have used A:M as part of a pipeline that uses other apps. Those may be helpful to you. Look for "MDD export" in particular.

Version on white canvas with paint tubes... ArtWhiteCanvas.mov Nothing new I notice. I have had trouble getting chor settings to stick so that first PRJ became a bug report.

There isn't a transportable version now.

It's all fluid particles from a moving emitter.

I was trying to get a Jackson Pollock effect... PaintArt.mov

It's a license. Like the subscription, it is locked to the computer you install it on. Like the subscription, it lets you run anything the comes out in the year after you activate. Unlike the subscription, it doesn't expire after one year, you can continue to run whatever versions you got during the year. You can't run versions that come out after that year. If I got that wrong, someone set me straight.

the long explanation can be very long, indeed.

Let's see, he did quite a bit on TWO i recall but it was under another screenname with a "jimmy" in it. Am I imagining that? Happy Birthday!

You could use a Light List to make the blue fill lights only shine on the ground. Or... You could make the ground bluer.

Just to try it and say "it can be done"... i can report that this sort of thing can be done. These things mostly depend on good strategy in A:M. I made my lathe outline so it would give splines in convenient places for splicing in a hole later. I only needed to splice in one hole. Once I got that one, I copied that one third of the shell with the duplicator wizard and attached the copies together Shell06.prj This took me about 90 minutes, which is probably longer than a person proficient with a polygon modeler would need. But I have had the experience in the past of setting up a Boolean punch in a polygon program, waiting 30 or so minutes for it do what it does, only to come back with a "Can't complete Boolean operation" error. So between needing two or three tries in the polygon modeler and one in A:M, maybe I'm not that far behind. This sort of form is a rare need in character animation, but if you need such an item in your A:M universe, it can be done without heavy lifting. If there is great desire I can do a screencam tut on this, but for most purposes, A:M's render Booleans will serve well and be quicker to model.

Good-looking entries!