robcat2075

Here's a thing i did to investigate my multi-pass problem. The challenge is that with many passes each individual pass becomes less visible as it is averaged into the whole. I made a tiny white dot and shined a VERY bright light on it so that the average value of the white pixels + all the background color passes remained high enough to be seen. With that, I tested all the possible number of passes as it traversed a path and composited the renders together here. Most of them are correctly subdivided, but a few, like 125, 144 and 169 fall short of where they should have gotten to on the path. Others, like 196 and 256, overshoot their goal and end up with multiple passes stacked on top of each other at the very end. Eventually this will be part of an AMreport.

that's interesting Nancy. I know I've tried some combination of Displacement and Bump and it didn't work. I'll give it another go.

Those are the disease-fighting white corpuscles!

Hi Simon, Several random notes... - you can't really use Bump and Displacement on the same surface because Displacement uses "bump" shading" for its light and dark effects. If you have Displacement somewhere, you're already using "Bump" and adding the same map as a Bump map gets no additional effect. -25% displacement is typically invisible in most circumstances. i usually end up with numbers > 100 - the Thatch bitmap probably wont' be an effective Displacement maker as it is not really an elevation map where bright = high and dark =low. Also it is stretched very large so that its pixels are huge as seen by the camera. Setting the repeat higher helps a little. different views have different amounts of the dark squares, I'm not sure what causes that yet. - If you REALLY don't want to embed models in your PRJ, then it is SO much easier when you are working on a project to make a folder for it and copy the models or any other asset you need to that dedicated folder and load from there instead of loading from different directories from all over your hard drive. "Consolidate" works but it's still not easy for the end user. It is way easier to have a PRJ that either already has everything embedded OR is only looking in one simple place for things it needs. This is also easier for you later when you return to a project and may have any of many circumstances that may make paths to files not the same as they were before.

Yes, I meant to post that, it is posted now under the episode 6 link.

Other problem i notice is that the hair is jittering. I've reported that too.

I've submitted an AMReport on it now. http://www.hash.com/reports/view.php?id=6496

Here's a simple PRJ i made in v18c that demonstrates some problems. This is hair with all default settings on a disc that is half white and half red. HairColorTest01.prj

That was very cheery! i needed that.

Charming adaptations, Nancy!

the master.log will be in the same folder as A:M I don't know what you mean by this. A preset just saves all the render settings. It doesn't affect any animation or models.

I loaded that PRJ in v18, went to render to file, used this preset Preset.pre and hit OK and it rendered fine. PNG worked also.

My guess is that there is something damaged about the file but it's hard to know without trying it.

Building to scale sounds prudent. The only thing i can think of that you HAVE to plan to scale for is Newton Dynamics. Is there anything else that has to be?

I like the character! There's probably some keyframing that would fix the sliding walk.

The different ways that "scale" can happen is something I've made a fair number of missteps on.

If you want to send me the v13 PRJ in a PM I'll look at it. It will need to have everything embedded. One quick way to find out what is causing a render crash is to delete stuff until it doesn't crash anymore.

Is this about rendering to AVI? Have you watched the Quickstart on Rendering? It shows how to choose "Full Frames (uncompressed)" for the AVI codec. Try that setting.

Why do you have to reapply decals? I've exported an OBJ and it had decals survive for the polygon app. Is "re-assigning" something else?

So, thinking this through a bit further... to use that other renderer you either need to use the stock materials it provides OR know a lot about real physical substances so that you can create new materials to accurately represent the substances not already covered by the stock materials. I think knowing a lot about real substances will be more technical than most 3D artists are up to. If creating new A:M materials is too hard for most people then creating new physically based materials will be too hard. I f the external renderer has an enormous library of ready-to-go materials that covers all the likely possibilities then that might not be a problem.

That's what I've always been wondering... I didn't see how it was possible to use an external renderer without redoing all the lights and textures in that other environment. So... it's not possible. You need to learn all the materials and lights of that other renderer to get the result that that renderer gets.

Problem solved now?

I believe particles have a default -y force you can set to any other direction. The chor also has a force property that is set to y=-100 i believe. Look for those. Reading your Q a bit closer... are you trying to get the particles to all converge on a single point?

Happy Birthday to you all! And a special shout to Jason1025, inventor of Light Dims Growing up in Minnesota we had a kids show called "Casey Jones" and at the end of every show he'd read off the names of kids who had birthdays while this song played in the background. wfSkqMP-L-4

That could be another "It can't be done"