robcat2075

I'm sure it can be done. Submit it as a feature request, if you haven't already. In the meantime I can imagine someone making a simple text editing app that, given a Chor set to render all the frames, would spit out X copies with each set to a different frame range. Then you'd just have to load each copy on to a different core and set it rendering without having to dig into each one to reset the frame ranges. Lessee... -this app would search thru the .CHO file for the defined frame range, -extract the start_frame and end_frame numbers, -extract the number_of_cores to be used from a string embedded in the PRJ title then, in a loop, write number_of_cores copies with Copy_0.cho set to render start_frame to end_frame, step=number_of_cores Copy_1.cho set to render start_frame+1 to end_frame, step=number_of_cores Copy_2.cho set to render start_frame+2 to end_frame, step=number_of_cores and so on until number_of_cores .cho files had been written out. (alternatively each copy could be set to render contiguous ranges if that was preferred.) that would be a simple program to write, there's probably a text editor out there with sufficient macro ability to do it.

Read the user notes for each one carefully. I believe MMoP needs that you have 'd a path for it to operate on. I think Multiply needs you to select a plane.

Just to check, in you Options>folders panel, make sure the path for extensions is pointing to the folder your extensions are really in. This can get confused if you have more than one version of A:M installed.

Based on what Steffen has said in the release notes, OpenMP is only implemented for certain parts the modeler. It speeds up the "finding patches" maneuver, which is noticeably slow on very,very large models. This is the pause when you get when you edit CPs on a model of say, 10,000 patches or more. So far, OpenMP hasn't lent itself to speeding up Final rendering routines. Your best bet for making use of multiple cores is still running multiple instances. It makes almost 100% use of each additional core which is far superior to any single instance/multithread scheme in any software. If you have multi-core machines NetRender probably isn't your best choice to make the most of them.

It doesn't have to be warm and fuzzy, the reversal on the troll might be quite grim for him.

No, haven't tried it since there's no case in which I'd want field rendered footage these days. In most CG field rendering makes things crawl more rather than less. But I haven't tried it. Also i don't even have a way to properly play field rendered footage. I suppose I'd have to burn a DVD and play it on an NTSC set.

You certainly can do similar things. The reason i go into materials for this was that I noticed displacement maps get a very grainy and/or stepped look at high displacement settings unless you used very high-res maps. Materials, on the other hand, have infinite resolution which makes them well-suited for creating the grey-scales that drive displacement. Displacement materials seem to have fewer of the blips that displacement maps have. Also, I like the stunt value of doing something that no one would have thought possible.

I hadn't caught this before. I like that it's all visual and doesn't depend on any dialog. Those ideas are rare. And the limited scope makes it feasible to do well. I agree with some previous comments that it needs a punchline or some other reversal for the troll at the end.

If you've made an action with a character, you can drop it on the same character in a chor to use it. If that isnt it, you may need to tell more about what you're trying to do.

Happy Birthday, David! I always enjoy seeing that image you made that is in TAoA:M. Good luck on the coming year and best wishes on your short!

The background color is in the camera properties. If you are wanting to composite A:M images over something else, turning on the alpha buffer in your render settings and using alpha channel transparency instead is way better.

You made me do it... A procedural material that makes... a propeller! propShadedFinal.mov It's quite slow to render, so I recommend everyone continue modeling your propellers as usual, but for the curious here's a PRJ with the the material Propeller05c.prj

Lets see... you know that common formats have 8bits or 256 values per channel... red green, blue, alpha. That's not many possible values, especailly for grayscale things like a depth map. But even for full color image processing it's not much. Do a severe gamma adjustment on a dark photograph to try to bring out detail in the dark...eventually you will see banding as the few values that the dark image is made up of get spread too far. In a HDR format like OpenEXR that almost never happens because each R G and B pixel is given not one of 256 possible values but one of billions. But why does that matter since we can tweak our CG lights to give us perfect exposures that we dont' need to adjust? Well... Have you watched Fuchur's intro to A:M Composite? Good starting point. With separate light buffers, each light's rays on the scene is like a different channel that you can raise or lower or even change color after you render. Need a light brighter or dimmer or gone entirely? With EXR renders you can do that and there's no need to redo a time-consuming render, just change a level in A:M composite and see the result instantly. It's quite magical. Right now A:M Composite is the only app I know of that really preserves the full precision of the EXR renders.

Thanks, I got the plugin - but I don't seem to be able to do anything with the exr files from A:M in PS 6.01, other than read them - and I haven't figured out how to generate the different channels in the exr file from A:M. I suspect I wouldn't be able to use them in AE 4.1 either (haven't tried). No, it won't separate any of the specialty buffers, although you could export those separately from an A:M Composite project to new EXR files and then open those in PS. I don't know id there's any app that can paint and edit EXR files in full floating point terms.

I've never seen that before. That's pretty sharp looking.

Yes. This makes the decal not get shadowed by anything and not need any particular light on it, Yes and yes. If you use the image decal to drive ambiance, then white will be white, but a 50% gray driven by 50% ambiance will only render 25% gray. 50% gray with 100% ambience will be 50% gray, which is what you want.

The standard route for a TV screen is to put the image decal on the screen surface and set the screen to 100% ambiance. That works. You'd have to show me a case where that is not appropriate. If you can't remodel your screen to the dimensions of your image then a still frame decal for ambiance would be the way to make just the image part luminous.

Show more than decals? yeah , have you got Skype? I'm rholmen. Send a contact request.

On the OpenEXR.org website there's a PS plugin for EXR. It converts the image to 16 bits which is better than 8 but less than what EXR can do.

smart idea. I have the same image applied in the same spot twice but one is for ambiance and one is for color. It gives me the look I want but I think this may be adding to the problem. Is there another method? Do you really need the image to do ambiance? Couldn't you just set the surface to an ambiance %? Not that two decals shouldn't work as well as one.

A slight blur post effect might also help in anti-aliasing instead of oversampling? Reduction in resolution of the original render averages the pixels in some manner which is a form of anti-aliasing. Same with blur. It looks to me like displacement runs into problems when it resolves to less than 1 pixel. That's what anti-aliasing is for. Well, let's try that. Here's the same three panels, but the top {original] render at the top is blurred 2 pixels, which is a lot of blur. treads11Single_blurredMP4.mov The flicker is still there, blurrier, but still obvious. Downsizing a larger render is the only way to get more actual anti-aliasing. But I'm glad even that works. I thought it was hopeless.

BTW, EXR also has a "flat" color buffer. I think it's "diffuse" An occlusion pass looks like a classic "White render". Much as Nancy hash shown.

Here's a comparison of single, double and triple resolution renders of the problem spot. Flickers and ripples are gone in the triple res render. treads11SingleDoubleTripleMP4.mov I'm sure it's slower. Also, Displacement only shades properly in multipass so you can't take advantage of faster regular renders. I'm finding that over-rendering helps in A:M too.

I know it's been used successfully before. The decal has a property somewhere for frame currently shown. Try setting keyframes on that.

Would >save as animation work? CHoose targa as the new format. EXR is treated like an image sequence. Use the Composite controls to turn off all the other buffers and then resave what's left to a new targa sequence.