robcat2075

Here's a slightly more detailed treatment of the tread. (I have no idea what is on the inside of tank treads.) Another day lost to A:M! I started this just before lunch and got the basic tread concept working in an hour, but then i couldn't leave it alone. Now my stomach is grumbling. I think you're limited to one displacement material on a surface. But you can model the bulge in the tire and spin the tread on the model, much as I'm doing here.

What would be the least obvious way to make tank treads? Tank treads made with, what else... procedural materials! The top is the final render, the bottom is the wireframe. treads9CompH264900.mov

What you are asking doesn't quite make sense. I suspect there are several terms confused. However, If you're on A:M v15 the OBJ importer will be included already If you just need to render the obj into a flat image you can RightMouseClick on the Objects folder in the PWS>Import>Prop The imported OBJ can be put in a chor and lit any way you want and you can render the scene to a TGA. Imported OBJ often look washed out or too bright. You will need to set the "ambiance" for all the groups in the object to zero.

Those are looking good. I agree. In the absence of scarve or capes or hair, a fundamental thing to do would be to pose them like they are moving forward fast. Have them grabbing the hand rail and leaning forward or... being pulled back. Anything but straight up and down.

You can adjust the angle and magnitude of the spline thru any CP with bias adjustments. Turn on the "Show Bias" button to see the adjuster. You can turn it and pull it to suit any shape. Shift and CTRL modify how it works.

When you turn the ALPHA buffer ON, the background will appear black ( aka nothing) until you use the image in an app that reads the alpha channel and lets whatever you put behind your render show thru the black. If you use the image in A:M as a rotoscope A:M will read the alpha channel and make the black part transparent. But when you first render your image it will look black since there is nothing behind it in the render window.

If A:Ms current regular render DOF effect could be allowed to produce a greater blur it would probably be quite good, it's already being driven by the depth map A:M uses internally.

You can constrain any model to a bone in any other model in the Chor. You can also drop a model in an action to use with a character in that action "Conforming" clothing... no. It would have to be a mesh specially modeled with bones in the right place to constrain to bones in the character model. I imagine Poser clothing isn't just any old model, it's a model made to work with whatever their conforming process needs.

IF you just need one still, I'd say model the new shape. You modeled the others, why not? That will be faster than trying things you're not sure of.

It's still not clear what the exact result you want is. If you merge those three components, only the section I've highlighted is derived from just yellow parts. Would that be the only yellow result, or would something be yellow if ANY of the sections was yellow? Or do they all get averaged? That's potentially 1x2x3x4x5=120 colors I think. If they don't get averaged, how are they prioritized, what color beats what color? And again... do you need to animate these merging together?

Actually that would be subtracted

And may all your patches face outward.

Making bones stay in place One of several tuts on keyframing on my screencam page. see link at bottom.

An exr depth map contains distance values from 0 to infinity (not values from 0 to 255). Where 0 is the camera lens and infinity is... infinity. If you want to focus on a distance 100 cm away, 100 is added to subtracted from all values. The DOF blur algorithm then interprets all pixels with values Pixels with values >0 are farther away and are blurred also but their blurs will be overlapped by pixels of objects that are nearer and less blurred. I presume the DOF filters work by starting with the pixel that is farthest away, blurring that and storing that result on a layer, then moving to the next closest pixel and blurring that. By working from back to front the correct overlaps can be imaged. That's probably oversimplified. The simple blurs in most image apps wont' be able to handle this. If you move your white zone to a mid round distance, they have no way of distinguishing the the gray zones in front and behind it for different treatment. There are some situations in which a simple blur will give approximately correct results but it wont' work in all.

A proper compositing app interprets the values in the map as distance values and that drives the DOF blur filter to blur/not blur the range you specify. Proper DOF simulation via a depth map will not work well with the typical blur filters in most apps (like Gaussian blur). A proper DOF blur filter understands that the blur of an out-of-focus background object should NOT overlap an in-focus middleground object and that the blur of an out-of-focus foreground object DOES overlap anything behind it and yet retains this sharpness of in-focus middle ground objects seen thru that blur.

What non-depth direction are you needing and for what?

But what happens when yellow intersects with another color? Or with two colors? What happens when red and blue intersect? Presuming that the colors represent a range of values, I would map that range to a gray scale, average the four gray maps together then re map the result back to the color range.

So the 2nd is what you don't want, but I'm still not sure what you do want. I suppose you want the yellow parts to appear as one contiguous section , but what do you want when red intersects blue for example?

I'm still curious about the black caterpillars. Did you solve that? Was that something that only showed up with DOF on?

Steffen Gross's Transfer AW plugin will try to re apportion weights from one mesh to another. That might do what you are trying to do in #2 if you used it on a copy of the old mesh and a copy of the changed mesh. However it is not documented. It is a replacement for the old Anzovin Weightmover app and I haven't really investigated it much. You would have to experiment with it.

and "orient like" You still have to be careful to not pull the arms farther than they would be able to reach anyway. Make the pose look right within the real limits of the arm. Don't go past that. An alternative to making the ball jostle a bit, would be to have his hands slip a bit on as he pulls them. That's a bit more complicated to keyframe, but it's another way showing that force is happening.

If you constrain the IK hands to the ball they shouldn't jitter so much. My advice on that move would be that when he yanks on the ball, have it move a tiny smidgen( and fall back). That will suggest that he's actually putting some force on it.

I took a quick look. One way to diagnose these things is to turn all the lights' Active properties OFF and then turn them on individually to see what they are doing. Keylight (4) seems to be causing the unwanted shadow. Turn that one OFF and see if the result is more like what you wanted. I'd have to look at it longer to figure out WHY it is doing that since it is a "sun" light and is aimed the same as the other sun lights. But turning off #4 solves the problem I think. If not, post a new picture and say what is still not right. Sun lights cast parallel rays over an infinitely wide area so their position shouldn't matter much, only their angle. You really should only need one sun light rather than 4 aimed in the same direction.

Thank you all, for your good wishes. I'm still not crazy about being 50. There's just no way to spin that to my advantage. Pineapple upside-down cake, mostly.

1- in the PWS you can drag-select all the keyframes and stretch them out to any length of time or 2- if you've dropped the action on a model in the chor you can set its "Cycle Length" property to any number of frames