PDA

View Full Version : Render passes increasing render time


ArchDragon
03-30-2011, 11:47 AM
Having a pretty serious problem getting Maya/Mental Ray's render passes to work properly for me.

I've been getting reasonable render times in the past (about 1 minute per frame), but as soon as I associate passes to a layer the render times go up to about 4 minutes per frame.

I've tried deteling all my layers and rebuilding. Currently I'm only using the masterLayer and even it is giving me the increased times. I've even tried importing everything into a new scene (after deleting all the layers and passes) and redoing all the render settings to no avail.

I can't seem to find threads on any website where other's have had this issue. Can anyone help out?

-Arch.

lipuster
03-30-2011, 08:53 PM
the increased render time is cos of your ao pass..remove your ao pass and render time will be bak to 1 frame. i render ao pass separately..also allows me to handle transparency. or you can instead use mia material's built in ao.

ArchDragon
03-30-2011, 11:43 PM
Hey lipuster,

I don't think that is the issue. I tested a few of the passes to see if I could narrow down to which one it was. It appears that ALL of them are currently increasing the render times slightly, and when you use all of them it blows the render out massively.

-------------------------

Okay, actually went back and tested your theory a little better and it turns out the AO pass alone is adding about 1 minute to the render times. I think I'll be taking your advice.

That said however, the other passes are still adding an additional 2 minutes to the render times, which I assume isn't supposed to happen. I'd still like to try and get around this if I can.

lipuster
03-31-2011, 04:13 AM
that's strange... am pretty sure of the behavious i mentiones and other passes have never incresed my render times at all. and the ao pass (with ao enabled in mr globals too) makes it approximately 4 times. i hope you unchecked ao in mr globals and didnt just remove the ao pass.
regards

SePu
03-31-2011, 05:23 AM
another pass that can cause render times go through the roof is the raw shadow pass ... I had problems with this one ...

ArchDragon
03-31-2011, 06:39 AM
@lipuster

It definitely is strange, and I'm afraid I'm only going to make it stranger.

I've actually got two animations that need to be rendered. The second one is giving me less issues and it seems your advice on the AO pass was correct. I've pretty well fixed that one.

The first one on the other hand is still misbehaving. I've done some rendering tests to see if I can isolate which pass is doing the damage, and although the AO is partly to blame, it's not the only one. Here are the results:

FRAMEBUFFER: RGBA (FLOAT) 4x32 BIT
EXR format

No Passes = 1.27
AO = 2.07
ambient = 1.33
diffuseNoShadow = 2.53
matte = 1.30
motionBlur = 1.35
reflection = 1.35
shadow = 3.06
specularNoShadow = 1.53

All Passes minus AO = 3.38


Obviously the AO pass is still an issue, but using a material override on another layer fixes that problem.

The problem now is the diffuseNoShadow pass and the shadow pass that are blowing things out. Is there any reason why this could happen?

Bitter
03-31-2011, 06:46 AM
What version of Maya? Previously Autodesk poorly implemented their framebuffer system with mental ray using a bad function that increased render times and memory consumption. (i.e. it's not mental ray, other 3rd party framebuffer systems made correctly did not suffer this problem.)

I want to say it was resolved or improved in 2010.

ArchDragon
03-31-2011, 07:04 AM
Hey Bitter,

I doubt that's the problem then. I'm using Maya 2011.

Bitter
03-31-2011, 07:15 AM
Might be interesting to test with a different framebuffer system but I don't currently have access to one. (Used to but deprecated now)

Might be a case to complain to Autodesk if you have support. just be sure you aren't using any "unsupported" (unexposed) shaders or they won't help you.

haggi
03-31-2011, 09:04 AM
Well, even if I didnt test it, there could be an explanation to the behaviour of shadow passes, especially for the noShadowPass.

Normally the lighting is evaluated in a lightloop. From this one you get the light contribution of the sampled point. In this loop the lights that will be blocked by some geometry will be skipped.

But in a noShadowPass you want to turn off this behaviour, and you want the light to illuminate the whole image without shadows. How can you do this? You'll have to shade the point twice. First turn off shadowing, evaluate the point, then turn the shadowing back on and shade the point again. Put the first result into the noShadowPass, the second into beauty pass.

If I'm right, all uses should see this behaviour. If not - well forget what I wrote... :)

Eshta
03-31-2011, 07:10 PM
What version of Maya? Previously Autodesk poorly implemented their framebuffer system with mental ray using a bad function that increased render times and memory consumption. (i.e. it's not mental ray, other 3rd party framebuffer systems made correctly did not suffer this problem.)

I want to say it was resolved or improved in 2010.
I Think you mean 2011
http://mayastation.typepad.com/maya-station/2010/04/slow-custom-framebuffer-render-now-fixed-in-2011.html

Redsand1080
03-31-2011, 09:47 PM
another pass that can cause render times go through the roof is the raw shadow pass ... I had problems with this one ...

This has been the most render intensive pass for me as well, even in Maya 2011.

ArchDragon
04-03-2011, 04:50 AM
Okay, think I've finally figured out what the issue is, although from what I understand it shouldn't be an issue. Maybe someone can help explain why.

The problem appears to not be the render passes as such, but the 'hold-out' feature I've turned off on the background passes. Switching it off makes my renders take about 10 minutes per frame, with it on they take 1.5 minutes per frame.

Can anyone at least explain why this is the case, or even better offer a way to fix it. I don't think it should be too big a deal, but I'm worried about getting the slight black outline around my character objects once I move on to post.

lipuster
04-03-2011, 05:06 AM
Hi,
interesting info there. So why have you turned off the hold out feature (im assuming its on by default..cant check now). is it that you are using pass contribution maps and the turning off holdout prevents the creations of holes (where objects are excluded from ur contribution map ) in the bg??

Regards.

ArchDragon
04-03-2011, 08:23 AM
Hi,
interesting info there. So why have you turned off the hold out feature (im assuming its on by default..cant check now). is it that you are using pass contribution maps and the turning off holdout prevents the creations of holes (where objects are excluded from ur contribution map ) in the bg??

Regards.

Bingo lipuster, that's exactly why I'd like to turn it off. It's on by default, which causes the cutout/holes effect you refered to. And this will quite often lead to a black line of pixels around your foreground object where it doesn't quite do the cut out perfect.

Redsand1080
04-03-2011, 01:35 PM
And this will quite often lead to a black line of pixels around your foreground object where it doesn't quite do the cut out perfect.

This could be caused by premultiplication not being handled correctly in whatever compositing app you are using. Can you confirm this is already being handled properly? Premult should be on by default coming out of mental ray.

When I've turned the hold out option off I've noticed a horrific increase in render times as well. The reason I've wanted to turn if off in the past isn't because of a black line of pixels however. I wanted to do split the scene up based on depth to get decent results from a post depth blur.

MasonDoran
04-03-2011, 08:26 PM
I posted this on DLF as well.

Holdout when Off, will render all of the culled objects behind the object, which is why you get the increased render times.

When color correcting in a comp app, you will have to Unpremult before doing any corrections, then premult when you done. You shouldnt be getting any black pixels.

ArchDragon
04-04-2011, 01:19 AM
I posted this on DLF as well.

Holdout when Off, will render all of the culled objects behind the object, which is why you get the increased render times.

When color correcting in a comp app, you will have to Unpremult before doing any corrections, then premult when you done. You shouldnt be getting any black pixels.

Hey Mason, I got your reponse on the DLF, but in the interest of giving the forums here the full information I'll respond here too.

The frame I've been testing on only has a tiny bit extra to render due to the hold-out. It would definitely be less than 5% of the screen size. Therefore I'd expect maybe a 5% increase in render time. Annoyingly what I'm getting though, is frames that go from 1.5 minutes to 20 minutes to render on my personal computer, and I've had frames take 2.5 hours over the farm. This is definitely more than a small increase due to the extra pixels.

I'm happy to say I've now got it working to the point I can finish the animation, but I'd still be really interested to know what's causing this and whether or not it's a bug that might be worth reporting.

lipuster
04-04-2011, 04:03 AM
hmmm.. looks like a buggy issue.

but if ur sole purpose in turning off holdout is to elimnate the black line, you dont need to. mr generates perfect holdouts.
u need to render with premult on and interpret your alpha properly in the compositing app (i.e, tell the app what's the color it has been premultiplied with..that wd be ur camera's env. colour. and if u r using physical sun nd sky, u need to chk use background while rendering so that its premultiplied wth solid black instead of some radient that cannot be unmultiplied properly.

Hope that makes sense.
Regards

Ash-Man
04-04-2011, 04:11 PM
Okay, think I've finally figured out what the issue is, although from what I understand it shouldn't be an issue. Maybe someone can help explain why.

The problem appears to not be the render passes as such, but the 'hold-out' feature I've turned off on the background passes. Switching it off makes my renders take about 10 minutes per frame, with it on they take 1.5 minutes per frame.

Can anyone at least explain why this is the case, or even better offer a way to fix it. I don't think it should be too big a deal, but I'm worried about getting the slight black outline around my character objects once I move on to post.
The hold out and custom pass still render ast on my side.
You might have something else acting beside that function

from the render passes white paper
For example, material overrides with a black surface shader could be used to perform hold-outs. Now, the same effect can be achieved by hiding the hold-out object using a pass contribution map, and turning-on the hold-out option in the pass attribute editor. The equivalent pass-based workflow is usually preferable because it is typically easier to set-up and it is usually faster to render multiple passes than multiple layers.

Redsand1080
04-04-2011, 08:28 PM
I did a number of tests comparing/contrasting the two workflows mentioned in the white paper: 1) render passes/contribution maps, 2) render layers, per object flags, and material overrides.

Based on these tests (which I can dig up and post if anyone is interested) it seems like the render pass/contribution map workflow works well with the hold out option turned on. However, as soon as you turn the hold out option off, the render layers workflow is much, much faster. Also, I noticed a number of firefly artifacts in reflections when using the mia_materials with contribution maps and hold out option turned off. With hold out option on, there were no fireflys. The contribution map workflow is, without a doubt, much easier to set up than the render layer method. But based on a couple weekends worth of testing, it appeared to me to be broken. I really wanted it to work, and invested a lot of time (including reading that white paper) into figuring out what I was doing wrong, but in the end I decided it was not an error on my part, but a flaw somewhere in the system. If anyone can demonstrate this is not the case, I would be more than willing to use this workflow instead of the render layers method.

In all of my tests I was trying to figure out the best way to split up a scene based on z depth in order to create post DOF with no edge artifacts.

Ash-Man
04-04-2011, 10:39 PM
My recommendations is to pack our sample files and report it as a BUG

Maya > help > report a problem

otherwise this will just slip in the wind without getting the Dev attention

Redsand1080
04-05-2011, 02:51 AM
My recommendations is to pack our sample files and report it as a BUG

Maya > help > report a problem

otherwise this will just slip in the wind without getting the Dev attention

I agree. I should have done this months ago. After wasting so much time trying to get this workflow to behave predictably, it seems ridiculous on my part to not take a few minutes and report the problem officially to Autodesk. I'll be doing this very soon.

EdtheHobbit
04-03-2012, 12:55 AM
Hey all,

Any word on whether this was addressed in the mental ray versions that shipped with maya 2012 or 2013?

Bitter
04-03-2012, 01:27 AM
There was/is a problem where the Autodesk framebuffer system will generate a ray increase (or explosion in some cases) for 2012, it has been reported for 2012 for sure.

2013 isn't out so not at liberty to say other than: I know it's being worked on by Autodesk and ARC.

You can see from the render diagnostic on a simple scene that a regular render generates a certain number of rays. Add one pass like world position (doesn't generate extra rays) and when you render you may see that there are in fact more rays this time (even transparency rays where there were none before.)

Contrast all buffers will increase render time for passes by default, as does adding passes that increase the workload (like occlusion) but the ray increase for passes that don't generate rays or trigger contrast sampling (vector passes) is a bug that exists.

RagingBull
04-16-2012, 10:15 AM
What's the situation these days with contribution maps and the render time anomalies ?

Bitter
04-16-2012, 02:20 PM
I don't use contribution maps, so I can't say.

However, the current tests indication render time increase (with contrast all buffers, "on") is as expected so far. There is a percentage increase because mental ray is doing more work, some areas that would be ignored are going to get more samples because previously unseen in the beauty. Adding something like an occlusion pass, etc add time as expected.

In one case for me 22 minutes without passes, 27 after adding passes, mattes and occlusion, etc.

That seems normal to me.

There may still be a bug occasionally triggered where rays are generated out of nowhere (like transparency, or sudden jumps in reflection/refraction) that needs reported if you see it.

Lastly: create passes correctly! Vector passes like normals and world points MUST be connected as vector (type n or m) and unfiltered. Adding them as color will trigger sampling with contrast which is wrong and will drive the sampler crazy. The should be unfiltered like z-depth anyway.

asche
04-17-2012, 02:31 AM
recently made a simple image (laptop with brushed aluminum) with maya 2012
it took about 20 hours to render in 5k x 3k with 10 passes.
after deleting the passes it took about 1 hour.
thats what i call buggy ....

Bitter
04-17-2012, 02:40 AM
How were these passes set up?

I have seen things like occlusion passes setup manually but were triggered for all ray interactions (most of which hidden) for highly raytraced scenes. It introduced an overhead by a factor of about 500%, but it was user error, not the passes.

Also, like I mentioned before, the vector passes need to be unfiltered vector (not color) passes or the sampler will sample to the maximum for every pixel. Numerical samples for say, a world points pass, will have large differences between samples, triggering even more. Vector passes do not do this.

***bug hunt***

Do you have an example of how your passes were set? If they were correct, try rendering a small portion with passes off. Look at the readout (with progress messages on). Render the same portion again (exactly the same) with maybe one pass on, look at the readout again. Were the eye rays the same? Were there suddenly many more rays of a type that were not there before? I have had that happen and they may need more scenes to reproduce the bug.

Bitter
04-17-2012, 02:47 AM
For example:

Say you render a section of a frame with 345000 eye rays

Add a vector pass, render again. You should *still* have 345000 eye rays. But were other rays suddenly created or multiplied? Maybe before it was 14 reflection rays per eye ray, but is now 39 or some higher number.

If that's the case, and it's not from the pass that was added, then it is indeed a bug.

Using the diagnostic readout may help you isolate *why* something took longer, like the above example of a ray explosion. That needs to be reported and something sent from the file to reproduce.

If that's not the case, or maybe just one type of ray freaks out, for my example I saw 1600!! probe rays per eye ray! When I looked at the network I saw it was connected strangely. It was a simple fix. That can get you up and running immediately when identified.

RagingBull
04-18-2012, 12:14 PM
Appreciate the input on this David :thumbsup:

CGTalk Moderation
04-18-2012, 12:14 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.