robcat2075

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.

Testing... Testing... Here's a TV test pattern made entirely from procedural materials. The Indian head is one material, the grayscale bar is one and everything else is another material. These are all made from spherical, grid and gradient combiners It would be possible to combine them all into one material but the graybar complicates that quite a bit.

As far as I am concerned A:M's depth of field has never been worth the render hit. You need so many passes and even then it never looks right. I agree A:M's DOF is quite time consuming. If you are using a compositing app like Aftereffects, creating DOF via a depth map and appropriate blur filter will be much more flexible and quicker.

Ding, ding, ding! That's exactly right. Or at least it's my distilled version of him. Just wanted to make sure I wasn't fooling myself about whether it looked like anything.

Render the first frame of this PRJ with "use settings from > The Camera". This renders a black frame with the vase's shadow in the alpha buffer. ShadowBufferTest.prj EDIT: This sample PRJ doesn't give the expected result in v19

This is a procedural material I made today. What does it look like?

Black caterpillars aside, that all looks uniformly blurred rather than blurred depending on distance. I have done a test somewhere here showing both DOFs working in their own way, but I don't know what your settings are. Is the caterpillar a one frame thing? on every frame? Same spot in the frame every time? On the same spot in a model every the time? Moving on a spline in a model? If I saw it in motion more would be known, possibly.

I'll guess the "Dan" was Dan Tiedy. Current whereabouts unknown. If you can make something that exports a "standard" that can be used with programs like Vue or Particle Illusion (or terragen) that would be great.

is that multipass or regular DOF blur?

Actually, I see I misunderstood Malo's reference to "Resurface". I was thinking of another program discussed elsewhere, probably not even called "Resurface" that attempted to make splines over polygon model. So basically, I initially misunderstood everything in Malo's first post.

Unfortunately, no. You have to judge it manually. When the prop is in shaded mode you can't see the splines over it at all, so it's not a perfect solution, but possibly useful.

Here... Is this what you are thinking... The head is an OBJ imported as a prop and placed in the chor. Model 1 started as just a spline to make a model that could also be placed in the chor. In the chor I selected Model 1 and then hit the Modeling Mode button to enable editing Model 1 with new splines and drew the new spline that is on the profile of the head. Doesn't work well in shaded mode, but this is what you were thinking except it's in the chor window, right?

Wonderful looking shot, Eric! How could we get that to work in animation? Probably the best live-action film Disney ever did. You oughta rent it.

I've re read your post a bit... I guess what you are wondering is if the "prop" could be a solid, uneditable shape in the modeling window, that you could model around with splines.... hmmm... that sounds plausible... but you can model splines in the chor already (hit the Thom button). Put a prop in the chor and model splines around it, that won't work?

The import of polygon models has been discussed many, many, many times here. Here's one.... http://www.hash.com/forums/index.php?s=&am...st&p=326235 Short answer... if it could be done, it would have been done long ago. You mean automatically? It wouldn't be any easier for a "prop" than a model. If ReSurface is doing an acceptable job, then just use it create mesh suitable for import. Short answer, I doubt it. There are too many other higher priorities that would need to be pushed aside for this one enormously difficult problem. Great looking models! You don't need polygon import!

Can you post a specific test case? Here's my 10 minute test case and it works... ConstraintToActionObject.prj Vase is a model. Action 1 is an action for Vase that uses Cylinder as an action object and moves it back an forth.; In the chor, Action 1 has been dropped onto Vase Sphere begins not being constrained to the action object, then is constrained to it starting at frame 20. From frame 20 onward Sphere moves with Cylinder.

more detail needed. in chor? in action? to what?

That looks great! Are his arms too short? Maybe it's just because he's tall?

in 8-bit color 128 is neutral grey(which means no displacement in a displacement map)so that leaves only 127 levels of displacement up or down. For small, sharp features like these windows it may not matter since the slope is greater over one pixel than the minimum slope that 1 level represents. Here's comparison of my dragon spike test, The first one uses a targa depth map, the second uses an EXR depth map. They are both the same resolution, but the greater precision of EXR allows every pixel to have an exact gray value rather than being rounded off to one of 256 levels. You can see the banding most on the body surface, where the neutral gray wasn't all exactly the same identical value. EXR is able to transition those small changes, TGA can't. There are other problems in both renders. In general displacement maps are interesting but not perfected yet.