robcat2075

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

Welcome to the forum! I'm not a mac guru, but this sounds familiar. I don't think your mac is inadequate. I guess closing and reopening that window didn't help. Is it just the library window? Are your graphic card drivers the up to date?

I'm sure there's a simple reason, but without knowing how everything is arranged in the chor and what's in front of what and what's not in front of what... it's hard to diagnose.

With 1 ray, shadows are automatically diminished as they stretch away from the object With > 1 ray they do not diminish but can have more accurate penumbras in their shadows. many light settings may play into your results, such as width, falloff, "darkness" and position and it's hard to judge those from the two images.

hmmm... I'll give that a try when I reconstruct my stuff for this. These little experiments are among the things lost with my hard drive.

How does he get into that? I don't see any zippers.

I recall that EXR renders include a separate AO buffer, but if your compositing app doesn't handle separate EXR buffers that won't do. A:M's "build composite" can do quite a bit with EXR renders but I haven't done much with it. Shadow buffers in EXR are a bit different than the TGA shadow buffer. TGA captures the whole shadow, even the part covered by the object, but only on surfaces set to "Shadow only" so I'm not sure how self shadowing is handled. An EXR shadow buffer has all the shadows cast by a light, but only the portion visible to the camera. These shadows are not convenient to blur in post like the TGA shadows are.. in TGAs, occlusion or Ambiant occlusion would be captured by doing an all-white render. All objects (and sky) white so that they are darkened only because of the lighting. In the Birn book he talks about how it is often necessary to capture different shadows on different surfaces in separate passes. It gets complicated when a shadow is falling on something that is also casting a shadow or casting a shadow on itself. You would need to analyze your scene to determine which shadows need to be captured separately from others, if at all.