Printable View
Lately our preprocessing times have grown unreasonably long. After you hit Go, it takes 10 - 15 minutes or more before the actual rendering begins. It used to be quick. What could possibly be making it take longer?
Core2 X6800, 4Gb RAM, ATI FireGL V3400.
Material libraries on the server, gigabit ethernet.
Various file sizes, small projects take a long time too, not just huge ones with lots of lights. Various resolutions - 75dpi to 300dpi, all seem to take too long.
Thanks for any ideas.
Maybe it's the .mlib, etc. on the server. I'd try it all on local drive and see if it makes a big difference.
I'd also try with your anti-virus shut off. Groundplane off may help, too.
Do you have lots of plants? I was rendering with many groundcover plants in the scene once and it really slowed things down. Had to shut them off with a filter until the final render.
Are you running a radiosity solution before ray tracing? If so, the preprocessing, gathering, etc can will take a long time especially with a lot of lights.(though its not as long as Maxwell, you can generate your radiosity solution overnight). A small project with a lot of lights, and with RPC's, can take a very long time to generate a radiosity solution. You'll get a very good image without any radiosity solution, though the radiosity will provide a much softer and accurate shadowed image.
One other thought. After generating the rendered scene, export the image, do not save the image, as then your project file becomes increasing large. Also, after exporting the image, select display model on the project manager, so the rendered image is removed from that view, and Revit doesn't have to redisplay a rendered view before it can start the new render study.
I'm basically going to second these guys responses. My experience is that one of my "typical" renderings -( 6" x 8" @300dpi - exterior / sun / no radiosity) usually takes about 1 to 2 hours on a comparable machine. And this is with a LOT of AR trees & groundcover. If I up the resolution or the size, the time obviously increases. However, this time is for the main rendering - where I'm actually seeing the image process. The 'back-n-black' preprocessing of the Voxel space usually lasts no more than 5-7 minutes on a very complex scene.
Without more info, my guess is you've got some radiosity going on - Do you have the box checked to recalc during each render? Also a local rendering file (.mlib) is HIGHLY recommended vs. over a network.
Good luck!
Kyle
Ok, thanks for the answers - I'll test some of these ideas. I've tried unchecking the 'soft shadows' and 'blurry reflections', but that's not helping. 'Recalculate radiosity' is NOT checked, so that's not the cause. I'll test with a local copy of the library, but in the long term, running with a local library will not be acceptable, as it would be a management nightmare keeping it current.
The image size is quite large (18"x12"), and 300 dpi, and there are quite a few lights.
Okay so now we know. You're trying to do a little too big of an image with those settings, unless you have a HUGE amount of Machine memory , and it will still take a long time to render then. You'll be much better off with a lower image size and adjusting in Photoshop.
Revit can create this image, but it won't be in an hour. Try your image at 6x9 at 150 DPI. If that renders Then bump to 300. Then if okay bump the dpi (not the size ) to 600. Then in Photoshop simply lower the dpi to 300 and increase the size to 12x18. It will essentially then be the same solution. EDIT: see my note below. If the LRaiz statement is correct (HA!!!) then my suggestion on the 600 DPI will take just as long to calculate at 6 x 9 x 600 as 300 x 12 x 18....
From a few years ago quoting Jeffery McGrew:
"That's why if you try to render a non-perspective view at 300 DPI it can crash out your machine, it will simply be too much info for the computer to deal with because your view might be 18" by 18" by 300 DPI... which means 5400 pixels on a side, or 29,160,000 total pixels!
This is also why doubling the DPI of an image quaduples the rendering time; an 5 x 5 image at 150 DPI is only 750 pixels on a side (562,500 pixels), where as a 5 x 5 at 300 DPI is now 1500 on a side (2,250,000 pixels - four times as much info)."
And remember each pixel will have 32 bits of color depth associated with it, so now your 32 times the number of pixels, both storing and calculating color, lights etc.
Refer to this discussion from 2004 on image size HERE
Trying to review this I found this from LRaiz , where he states"You should not be concerned that 100 dpi seems to be low and modern printers have much higher resolution. Accurender will shoot a single ray of ray-tracing for every 1/100" by 1/100" square of the final picture.."
Which implys then that you are asking Revit at 12x18 x 300 DPI to shoot and caculate a single ray while ray tracing for every 1/300x1/300 square of the final picture (19,440,000 ray calculations - if my math is correct). That should take a while no matter what machine you're on.
...or your image size is huge... Oh wait.. That's the ticket! Good catch Ski. Although, I must say I've done 11x17 (not that far off of 12x18s) at 300dpi before... and i think the most i've waited for that was about 4 hours. (I'd have to go back and look in one of my journals). But you're absolutely correct - do it as reasonably small as possible, then up it in PhotoShop.
Kyle
p.s. - did a search for that file. Here's the LINK to the thread I had. The final 11x17 images were 5100x3300 x 300dpi JPGs. I threw these images into Photoshop, and blew them up to print as 24x36 posters just fine. Although I was worried - the final prints looked fabulous.
I told Daniel last night that it's probably because the Accurender DLLs are being networked. We had the same problem in my office and once we copied the AccuRenderRedist folder to each computer the problem was solved. We still have an .mlib file we keep on the server along with the JPGs for non-OOTB textures (OOTB textures are still stored on each computer), so materials can still be shared around the office. Works great.
You da man, Wes - I set it up as you suggested, with OOTB mlib and textures copied to the local machine, but keeping our customized office mlib and materials on the server. Works like a charm! Preprocessing takes seconds instead of many minutes.
I still can't figure out why it would have suddenly started taking a long time, when we didn't change anything in the setup, but I'll take the solution and move on.
Thanks for your help, all.