PDA

View Full Version : Render Optimization Thread


Bonedaddy
02-14-2004, 08:35 PM
Hey all,

I haven't found much collected information on making your render as speedy as possible, so I thought I'd start this thread, see if it helps people. Just post suggestions on things people can do that will speed up render time.

Suggestions I can think of off the top of my head:

1) Bake out as much as you can. This applies to lighting, textures, shadows, and occasionally stuff like displacement maps.
2) LOD and cards. Once you've figured out your camera move, you can even start substituting a lot of cards for expensively rendered objects. A lot of details you don't need to model; you can just paint and use cards.
3) Render in layers. Rather than trying to get it to come out perfect straight out of your 3d package, give yourself as much leeway to tweak the colors, brightness, etc. in compositing.
4) Maya and Mental Ray : this thread (http://www.cgtalk.com/showthread.php?s=&threadid=122818) deals with how to optimize textures for render time.
4) Maya and Mental Ray : Displacement Approximation can speed up render times on MR-displaced objects immensely.
5) Maya only: File->Optimize Scene Size can clean up unused nodes and speed up render time.

lazzhar
02-14-2004, 09:15 PM
Good idea.

I only have this in mind:
Dont use rendering techniques that takes too much to render until you need them. So use d-map shadows intsead of raytraced shadows, reflection mapping instead of raytraced reflections, fake GI with fill lights..etc

For Displacement, DOF and Motion Blur, using Renderman should increase the speed too much as i've tested by myself.

Andrew W
02-15-2004, 09:34 AM
A few off the top of my head:

1) Different resolutioms of texturemap. If you have an object on the horizon, it doesn't need a 4k texture on it. LODing for textures basically.
2) Render everything in passes. If your beloved client decides they want a bit more spec, then you can add it in the comp rather than re-rendering the whole thing.
3) If optimising in Maya be aware that some nodes (often light linking one) claim to be undeletable. Time to open up a text editor and get your hands dirty.
4) If you're using RenderMan use Delayed ReadArchive as much as possible. This will prevent you from having to load geometry till your scene needs it.
5)Use points and curve rendering wherever possible, they are super efficient. Ditto for procedural primitives supported by your renderer.
6) All maps of any sort should be binary in size (128,256,512,1024, etc.).

I'll post more when I think of them.

A

lazzhar
02-15-2004, 10:01 AM
>>6) All maps of any sort should be binary in size (128,256,512,1024, etc.).

AFAIK, in renderman you have to convert all your textures to a square size ( 128x128... 1024x1024) I guess this renderer is optimized for that.

I'm asking, what about other renderers? do they also need square textures?

Bonedaddy
02-15-2004, 06:02 PM
These SIGGRAPH course notes (http://www.renderman.org/RMR/Books/sig02.course16.pdf.gz), while Renderman-based, are invaluable to anyone looking to do this stuff correctly. Their workflow for production Global Illumination, especially, would be handy for many people. Chapters 1-3 are a little technical, but Chapter 4-5 are solid gold, and explain a lot of what Andrew W was talking about.
I seem to recall reading somewhere that texture LOD wasn't THAT big a deal, in that most renderers mip-mapped it anyways. Of course, having the memory to hold a 4k image is important, but for continuity's sake, it's good to use the same texture. Am I wrong?
lazzhar : I think that only Renderman is to the level of fussiness to only accept binary images, but other renderers automatically convert images to binary anyways at rendertime, so you'd be skipping a step for them.

Andrew W
02-16-2004, 08:27 AM
Originally posted by Bonedaddy
These SIGGRAPH course notes (http://www.renderman.org/RMR/Books/sig02.course16.pdf.gz), while Renderman-based, are invaluable to anyone looking to do this stuff correctly. Their workflow for production Global Illumination, especially, would be handy for many people. Chapters 1-3 are a little technical, but Chapter 4-5 are solid gold, and explain a lot of what Andrew W was talking about.
I seem to recall reading somewhere that texture LOD wasn't THAT big a deal, in that most renderers mip-mapped it anyways. Of course, having the memory to hold a 4k image is important, but for continuity's sake, it's good to use the same texture. Am I wrong?
lazzhar : I think that only Renderman is to the level of fussiness to only accept binary images, but other renderers automatically convert images to binary anyways at rendertime, so you'd be skipping a step for them.

Texture res is important more for network speed than the actual renderer. And that goes for any renderer. If you're working with a farm and you've 50 machines all trying to pull the same set of 25 4K textures things are going to slow down in a big way. Plus many renderers' cache for textures isn't that great either. PRMan defaults to a paltry 10mb, though it's very easy to change this in the config, or per-render. You have to think about your whole pipeline, not just the box, but also what it's connected to. If you rely on mip-mapping you have to trust that your renderer is making the transition at an appropriate point and that its blending method is to your liking. Paint your maps big, then make lower res versions of them would be my suggestion.

The holy rule is ALL RENDERERS LIKE BINARY RES IMAGES FOR EVERYTHING. Can't stress that enough. PRMan just forces you to use binary images to prevent the user from accidentally using an inefficient res.

A

CGTalk Moderation
01-17-2006, 10:00 AM
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.