robcat2075

The advice to break it into sub-models is the best path, but I'll note that if you have a multi-core CPU, checking Tools>Options>Global>EnableOpenMP should get you some performance increase on large models.

It is very jarring to see the early, fat version of Elmer Fudd...

For now... I'd say render twice. If you turn all the lights off and turn off the toon, the depth maps should render fast.

You want the windows to have the same depth as the walls? Try making them 99% transparent instead of 100% transparent and see what happens.

Here's a quick test of what i think you are describing... -On the top, this square grid has the left side is set to 0% transparency and the right side is set to 100% transparency -in the middle is the final render that looks correct -on the bottom is the depth TGA from that render. It seems to appropriately regard the transparent section as "not there" for distance purposes. If I set the transparency to the right section of 50% the depth map regards the whole square as "there" with no difference in the depth map between the left and right sides of the square. That would be the correct assessment of "depth" I haven't tried this with an OpenEXR render to see what that depth buffer does. Here's the PRJ you can try and the render settings I used... DepthmapTest.prj TestPreset.pre

It may be a limitation of the way depth maps calculated. What if you used the fog method fro creating a depth map? Does that have any more correct result?

White would signify infinite distance, so what you are saying is that there si something behind the transparency that is not infinitely far away?

Here's a torture test of 4096 subdivision. Small text on large patches... The top model is just two patches with a displacement map applied to create "Raised Text" The middle is the STL export of the top model, re-imported into a model (not as a prop). 16384 triangle faces. The bottom is the same, but in shaded view. If there were more patches there to subdivide, the result would probably be smoother.

If you can just get your foot in the door...

I'm glad you're getting a leg up on this project.

Ya know... we ought to just do it and put a Make Dragon button in there. A button that pastes a finished, rigged dragon into the modeling window.

Most of those I have not seen before!

Is the band getting more gigs now that they have a hit video?

that looks better!

Impressive work as always, Rodger!

In this case I'm talking about the bias>magnitude. Alpha and gamma are like a twist in the direction of the spline through the CP. Magnitude is like a stiffness of the spline as it goes through the CP Here are three copies of a spline that is bent like your tree. The magnitude of the CPs on the top have the default 100%. The second one has a higher magnitude, it looks lumpy, like your tree. The third one has a low magnitude, it has sharper corners. Magnitude has separate In and Out values. You don't know which side is In or Out until you try. You can change a bias directly with the bias handle or by numbers in the Properites. You can change several selected CPs at once with either method.

Not yet. I don't think any particular feature is certain yet.

On your tree... it looks like you have the bias of the splines that run vertically up the tree trunk set to some large value and that is what is making it not bend smoothly.

that's looking fierce.

My will give you some general info. It looks like you've been rotating the bone mostly along one axis and that's why one curve (the red) is most curvy. You can edit the shape of those curve much like you can edit splines in the modeler. Turning on "Show Bias handles" works in this curve editor for adjusting the slope thru a CP. You can also experiment with an edit by grabbing a PC, sliding it up and down and observing how that changes the bone in the animation. The reverse also works. You can move the bone in the animation window and see how that changes the curves. basically , yes. steep lines mean the value is changing fast and not-steep lines mean the value is not changing much. The actual numbers aren't too important, the steepness/flatness is. Note that the window typically only shows curves for what is selected. You have one bone selected so only the curves for one bone show. You can CTRL-select several bones to make curves for several of them display if you want to study several or grab and move their keys together.

Happy Birthday on the other side of the world!

It's the most helpful forum in forumdom. If you have a question about A:M, I guarantee some smartypants here can help you out. I have my smartpants on most of the time.

I was disappointed to find out Mike was running an anti-A:M forum and creating a lot of negative word-of-mouth. That was very damaging.

Here's an oddity. This may be a problem with "prop" rendering rather than STL itself I put a map with some text on a torus and exported it to 4096 with "apply displacement to geometry", then imported it back in as a prop. The map appears to be properly converted and the detail looks to be adequate but the raised surfaces don't' shade right in realtime or in render

Pixelplucker... what's making the waffle look in those images?