Jump to content

Rendering with MR proxies increases render times?


Cad64
 Share

Recommended Posts

Ok, I'm a bit confused now. I thought MR proxies were supposed to help speed up render times, not drag them down? We're in the process of upgrading from Max 9 to Max 2010. One of the main reasons for this upgrade is because of everything I've read about how great proxies are and how they help speed up render time.

 

I'm using the Max 2010 trial version right now, and I've put together a simple scene filled with Xfrog trees. 18 trees to be exact. I set up my camera, environment, render settings, etc. and rendered the scene in 13 minutes, 24 seconds.

 

Then I created a copy of this file and replaced the trees with MR proxies. I inserted one proxy and then instanced it to each tree location and then deleted the trees. Everything else is the same as the previous scene. Obviously the scene is much lighter and much easier to work with now, but my render time increased to 15 minutes, 29 seconds. :eek:

 

What gives? Why does it take longer to render with proxies? Is there some setting I'm not aware of? Am I doing something wrong? Or is this rumor about speed increase just a big lie to get you to upgrade? If so, I'm in big trouble, because I've been really pushing for this upgrade, and my biggest selling point was the advantage of proxies.

 

BTW, I used BSP with the scanline algorithm enabled for the above time.

When I switch to BSP2 & disabled scanline, the render time goes to 15 min. 31 sec.

 

I hope someone has some words of wisdom for me, otherwise I'm gonna get my butt kicked tomorrow when I present these render times. :(

Link to comment
Share on other sites

I'm not an expert on Proxies, but I think they are designed to save memory.

I know when I turn objects into proxies and hit Render, it has to translate or ...something. I don't know if it's a one-off hit or if it has to 'translate' for each proxy type.

 

For example: I have 3 different types of trees - Style A, Style B and Style C.

I don't think it matters how many of the various styles you have, I think it takes 'x' amount of time to bring in Style A, 'x' amount of time to bring in Style B & 'x' amount of time to bring in Style C.

 

So if I understand it correctly, this would NOT save you any time or (much) memory if you have only a few items/proxies. However, it would let a scene that would not render (for example, 5000 trees) become renderable.

 

I might be completely wrong, but that's my take on it.

Link to comment
Share on other sites

Thanks Sandman, I guess I'm just back to square one. I thought proxies were going to be a big help, but it looks like they are just going to be more trouble than they're worth. If they're going to increase render time, then what's the point. I'll just continue using Xrefs and keep doing what I've been doing. And I guess we'll just stick with Max 9 and save the $2k we were going to have to pay in order to upgrade. I'm just glad I found out now, so at least I can save us some cash.

Link to comment
Share on other sites

Hmmmm, I just discovered something very interesting. I found a script HERE which I used to create proxies of all the trees in my original file. It works great as far as converting all instances of the trees to proxies and deleting the original geometry all in one swift motion. It also helped tremendously with my render time. It's now down to 13 minutes 20 seconds. 4 seconds faster than the original file. I must have done something wrong in the original proxy file?

 

I'm happy again and will continue on with the upgrade to 2010. :D

Link to comment
Share on other sites

If they're going to increase render time, then what's the point.

 

The point is to render lots of geometry without running out of RAM. This is something that really can't be done effectively without proxy objects. With proxy objects, the render engine has the ability to load, and unload geometry while the rendering process is happening.

 

Attached is the a tree pass frame from an animation we are putting together. The scene has over 7,000 trees in it, and about 6,000 bushes. In the past this would need to be done with "billboards." With proxies, they it can be done with geometry.

Link to comment
Share on other sites

I was under the impression that proxies would decrease render times, but I guess that's not really the case. At least my render time is now the same whether I use them or not, so that's good. And they definitely help with performance while working, so I am thankful for that. I just got a little irritated when I saw that 2 minute time increase on my first attempts. I'm still not sure what I did wrong with that first file? But all is good now. :)

 

Thanks for the reply.

Link to comment
Share on other sites

  • 2 months later...

As long as you have enough RAM, extra geometry does not effect render time as much as you might think. After the information loads, the actual render time for that image was probably not bad. I will need to check tomorrow or the next day for actual time, but I would guess around 7 - 8 minutes at the resolution I am showing. But again, that is after the information loads, which can take awhile.

 

Render time is effected more by AA and sampling of the image, & glossy samples /subdivisions of the materials. If you are very cautious and conscious of how you are using those two items, you should be able to keep the render times fairly reasonable. There are other items that effect render time, but those are the main areas outside of lighting calculations, and load time.

 

Glossy Samples = MR

Subdivisions - VRay

 

Now, that said, extra geometry make a file a pain in the ass to work with and set up. Also, lots of geometry with poorly constructed materials will take a ton of time.

 

But take the image I posted. It was part of a two pass rendering. In this pass, the building had no materials, and all of the other materials are fairly simply with no actual reflection. The leaves on the trees are 4 vertex geometry, with no opacity/cutout mapping, just vertex mapping for the those.

 

The second pass had the building with full materials, and glossy reflections, etc.. Keeping them separate helped keep render times efficient. The second pass also had a lot fewer trees, meaning less calculations had to be made in the reflections.

 

Billboards are not necessarily a faster solution. The scene will load quite a bit faster because there isn't as much info, but calculating and rendering cutouts can be quite time consuming. I know there are some work arounds, but I don't know how much they actually cut down on render time.

Edited by Crazy Homeless Guy
Link to comment
Share on other sites

"As long as you have enough RAM, extra geometry does not effect render time as much as you might think. After the information loads, the actual render time for that image was probably not bad"

 

Ok are you separating load time from the render time? Seems like comparing apples and oranges.

 

Load time happens after you hit the render button, correct? So I consider it part of render time.

 

How much "load time" is involved with your 7000 tree scene?

 

Thanks!

Link to comment
Share on other sites

"As long as you have enough RAM, extra geometry does not effect render time as much as you might think. After the information loads, the actual render time for that image was probably not bad"

 

Ok are you separating load time from the render time? Seems like comparing apples and oranges.

 

Load time happens after you hit the render button, correct? So I consider it part of render time.

 

How much "load time" is involved with your 7000 tree scene?

 

Thanks!

 

I still haven't had a chance to check it. Last week was busy.

 

Yes, I am separating load time and render time. If you are running an animation, the scene only needs to load once, and then it can reuse that loaded information on each frame, therefore becoming nearly irrelevant after the first frame. This doesn't help with single images.

 

Also, MR tends to have long load times for geometry compared to other engines I have used. I am not sure why. I am throwing a lot more geometry at MR than I have any other engine, so maybe it is just a result of that.

Edited by Crazy Homeless Guy
Link to comment
Share on other sites

A note on xFrog trees and the like with cutout or opacity map leaves. This method creates significant slow down with Final Gather. So much so that you could be better off with geometry in place of opacity mapped leaves. Jeff Patton talks about it on his blog. Besides xFrog tress have rather high poly leaf planes as it is. You could have full geometry leaves with the same number of polys. Just something to keep in mind.

Link to comment
Share on other sites

Samuel is correct. Avoid opacity and cutout maps in nearly all cases. They slow down your scene. This is true of Onyx trees, and any other item where it may seem appropriate to use a cutout map. IE perforated metal, or something along those lines.

 

So, I got around to digging up that scene I posted before, and running a few tests in regards to time:

 

Basic Machine Specs...

 

Dual Quad Core 3.0ghz Xeon's

8gb Ram

 

Scene Times...

 

Sampling at 1:16, Box AA at 3 3, Spatial at 0.05 on all slots, Resolution 1280x720

 

Load = 1'40"

First Frame = 5'41"

Second Frame and Subsequent = 3'46"

 

 

Sampling at 4:16, Box AA at 3 3, Spatial at 0.05 on all slots, Resolution 1280x720

 

Load = 1'40"

First Frame = 6'13"

Second Frame and Subsequent = 4'32"

 

The RAM used for both was slightly above/below 5 gigs. I also only had 3 reflections/refractions. As mentioned earlier, this scene was for a tree pass, with geometry for leaves, and no need for reflections refractions.

 

One thing I have been struggling with is the Sampling and AA setting for MR. I can't seem to get the nailed down as easily as I can with Vray. Some of this can be blamed on other changes in working methods. I am now using mostly Revit geometry, which is created by others, and often contains very thin gaps and joints which are no picnic. But even the trees, which I could animate smoothly in Vray with ease have proven to be a problem.

 

The obvious solution is to start upping my sampling and AA settings, but the higher I go, the more of a hit on render times. This is one area where I have not been able to get MR to behave as well as Vray.

 

The 3 3 box for AA is quite blurry also. I probably should have gone 2 2, and lowered the spatial contrast. I could really use higher than 4:16 on AA, but I am afraid of what it will do to render times.

 

But... this is 720p resolution, and my speeds are fairly fast. However, once I start adding building materials in the speeds can easily slow down depending on how careful you are. Glossy/blurry reflections at material level can cause greater slow down than the global sampling/AA levels. Any advice in this area would be greatly appreciated.

 

Edit: Also, this is a lower camera than my previous image post of this scene. Had I used the same location on the camera path, my render times would have been higher because there are more trees in the scene.

Edited by Crazy Homeless Guy
Link to comment
Share on other sites

WOW those times are low. I need to do a test. I didnt know this was possible.

 

So I import an onyx tree then make it a mental ray proxy and "clone instance"

 

Is this correct?

 

Thanks again

 

Yes. Also, in order to get the benefit of proxies, you need to disable Scanline, and set the Raytrace Acceleration to BSP2.

 

BSP2 is able to flush memory, Scanline and BSP can not.

Link to comment
Share on other sites

  • 1 month later...

 

The 3 3 box for AA is quite blurry also. I probably should have gone 2 2, and lowered the spatial contrast. I could really use higher than 4:16 on AA, but I am afraid of what it will do to render times.

 

 

Just saw this post, i realise its a couple of weeks old.

CrazyHomeless guy, Have you tried using Mitchell AA filter ? I find it handles edges better and you only really need it on 1/16.

 

cheers

Link to comment
Share on other sites

Just saw this post, i realise its a couple of weeks old.

CrazyHomeless guy, Have you tried using Mitchell AA filter ? I find it handles edges better and you only really need it on 1/16.

 

cheers

 

This was for an animation. Mitchell is a sharpening filter, which is not ideal for animations. I typically render 1/16, but at 1/16 the leaves on the trees were still dancing around.

 

Actually, lately I have been using Box at 1 - 1 with 1/16 sampling for my stills, then applying a slight sharpen in post with unsharp mask. Sometimes I can shave 10-20% off my render time by using a non sharpening filter.

Link to comment
Share on other sites

This was for an animation. Mitchell is a sharpening filter, which is not ideal for animations. I typically render 1/16, but at 1/16 the leaves on the trees were still dancing around.

 

Actually, lately I have been using Box at 1 - 1 with 1/16 sampling for my stills, then applying a slight sharpen in post with unsharp mask. Sometimes I can shave 10-20% off my render time by using a non sharpening filter.

 

Aaah I see animation is a different beast.

I should try your BOX settings, see I can get better render times.

 

cheers

Link to comment
Share on other sites

I have been playing with spacial contrast, what I have noticed is darkening the sp improves the AA quality but increases the rendertime. Understandably so as its doing more Max AA samples.

 

jhv

 

I tried going all the way down to 0.005 at one point, but even that didn't stop the dancing. I wonder how my render times would compare if I rendered a 1.00 spatial contrast, with 16-64 sampling settings.

 

Hmmmm.... Probably won't do anything for me, but it might be an interesting test.

Link to comment
Share on other sites

I like to render my frames 2X or possibly 3X the final res with really low sampling like 1, 4 and down sample them in post. The basic idea is to give the render more pixels to work with, rather than making fewer pixel work harder.

 

The rendertimes are quicker and the final images are crisp, with good small detail and no dancing.

 

Big downsides are the larger file sizes and the time it takes to down size a long animation.

 

jhv

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...