r1 - 09 Apr 2007 - 19:19:56 - MattEstelaYou are here: TWiki >  Maya Web > TWikiAdminGroup > MayaMisc > MayaModelling > MayaOptimisingRenders

Optimsing Maya Renders

This was taken from a great post to the highend3d list, unfortunately I've lost the authors name. If anyone knows who it was, please let me know, and I'll add their name here (or take it down if they'd prefer).

After some research here is some guidelines for getting the most out of Maya. Thought I would share it

with you:

General Performance

  • if you're running many rendering jobs on a multi-processor: it might be faster if you turned off '''Render Globals->use File Cache'''. This is because th I/O will likely dominate and slow down all the rendering jobs.

  • avoid motion blurring everything: if you have objects which are not moving, or barely moving, don't motion blur those objects. It'll render faster, and produce higher quality imagery. Motion blurring can be turned off on a per object basis.

  • avoid shadow casting for every light: shadows are expensive, avoid for all lights. Be selective. You might also want to avoid shadow casting surfaces. The fewer shadow casting surfaces the faster the shadow map generation/shadow casting will be. The smaller the world space bound of the shadow casters the higher the density of the shadow maps. (ie, better quality shadows).

  • reuse shadow map: on a per light basis, you can choose to reuse the shadow map generated only once (at the beginnning of rendering). By reusing this shadow map, you avoid producing shadow maps for subsequent frames. This can be a significant savings in time, and potentially some memory (due to less fragmentation). This only works properly if nothing in the database, other than the camera, changes over subsequent frames.

  • shading samples: Quality->Shading Samples, Quality->Max Shading Samples, Shape->shading samples. Don't just bump up the shading sample (represents the minimum #shading samples per pixel) value to get good quality images. It is best to keep this value as low as possible for performance efficiency, allow the adaptive nature of our algorithm to catch color differences. Keep this to either 1 or 2. Increasing the max shading sample is more reasonable, as it is the upper bound for #shading samples when the adaptvie algorithm catches color differences. If you have small, specific set of objects that are very noisy and require many shading samples to get a good quality, just set the shading samples override on a per object basis - then the rest of the scene is not penalized by just the noisy nature of this object.

  • visibility samples: Quality->Visibility Samples,. This is only relevant for motion blur. If jagged edges appear, this is likely due to visibility samples. But instead of increasing the minimum visibility samples, please increase the max visibility samples first, with the first attempt at 8 max visibility samples.

  • convert solid to texture. If you are using a very expensive procedural texture, instead of computing the procedural at each sample, you can use convert-solid-to-texture to produce a file texture representing a snapshot of the procedural texture onto the object. The file texture usually prove to be much faster. It also comes with filtering, which may bring better anti-aliased quality to the procedural texture as well.

  • share textures: unlike PA/studio, it is easy to share the same texture node. It is much more optimal, storage wise, to have such sharing. the most optimal image file format to use: IFF. This will help in batch rendering, but mostly during the interaction with the multi- lister. If you know a certain image file will be used often as a file texture, converting this file to IFF will help performance.

Raytracing Performance

  • avoid raytracing everything: be selective what you need to raytrace. Raytracing is an expensive process. Even for transparent objects which do not require refraction, don't raytrace.

  • reflection, refraction, shadow limits: Quality->Reflections, Quality->Refractions, Quality->shadows. Keep these numbers low, particularly the reflections and shadows. Usually 1 bounce of reflection is more than sufficient to have mirror effects. If the limits are higher, potentially much more raytracing will be done, even at 2 bounces of reflection (in conjunction with refraction).

  • whenever possible, use depth map, shadow casting lights instead of raytracing shadows.

  • avoid huge floors: if you have a huge floor with very complex geometry occupying one small region, this will slow down the raytracer. Scale down the floor so you can still get the raytracing you want.

Preview Performance

  • render active: Globals->Renderable Objects. You can render selected objects if you wish to, by turning on this option, then selecting the active objects in the modeling view. There is no need to select a light (as you do in PA) - all lights are assumed to be lighting the active objects.

  • partial image rendering: you can select a marquee region to do partial image rendering. This will save you time from rendering the entire scene. This can be used in conjunction with the render active option above to save even more time.

  • turn off all shadows: Globals->Enable Depth Maps. For quick previews without any shadowing, you can quickly disable all depth map, shadow casting lights with this option.

  • turn off specific lights: by hiding the light, you have explicitly indicated that you want to turn off that light. So no lighting will come from this hidden light. This can save you time from avoiding to with this light, which might be insignificant in the area of your concentration.

  • reuse shadow map: if shadows are absolutely needed in your preiews, and if you only intend to modify lighting colors or shader/texture attributes, you can save the shadow map, then ask it to be reused during subsequent preview renders. Then the shadow map prepass can be avoided, for faster previews.

Controlling Memory

  • memory cap: Globals->Maximum Memory. Keeping this at 64mb is usually a good idea, unless you have lots of memory. If you find that you are swapping too much, lowering this value will help. A limit of 64mb means the renderer will try to use at most this amount. There will still be other users of memory beyond this limit: memory used by the database, and memory used by texture maps. The database memory can easily be swapped out during rendering, so it is not a concern. Memory capping texture maps require the below solution.

  • use texture file cache: Globals->Use File Cache. This can be turned on a per texture basis, in which mipmap tiles can be cached into RAM from disk. This means that the entire mipmap does not need to be in RAM all at the same time. There is a global cache keeping track of the mipmap tiles of all the texture files (with the cache turned on), and it is retrieved and dumped on a LRU basis. This global cache then keeps the entire set of textures' memory down (usually to less than a meg). To use this cache, it is even best to save the image files as the native mipmap format, or as we call it, the BOT (block ordered texture) format.

  • reuse tessellation: Globals->Reuse Tessellations. This is ideal only when you have more than 1 shadow casting light. Then an object is tessellated at most once. But keeping the tessellation around means more memory used (some is swapped out if the memory cap is hit). If memory is really low, turning this option off can help.

  • don't over-tessellate: always keep the triangle count down. If some object can be single-sided, mark it as such. If it is a degree 1 surface, set the tessellation to 1x1 with no secondary criteria. If an object is insignificant in your rendering, lower the tessellation.

  • shadow maps: if you have a high resolution shadow map for point lights, the memory used up is several times more than spotlights - this is because multiple shadow maps are needed. One way to save on memory for pointlights is to choose which direction (of the 6 directions forming a cube) shadow casting is really needed for your scene. This will save memory and performance.

  • out of disk space: to avoid over-burdening RAM, a temporary file is written out to disk to avoid system swapping (which is very slow). But on out-of-disk situation, particulary on really big databases, this can lead to system swapping easily. The temporary file is usually written to /usr/tmp. If you have a partiton in which you have plenty of disk space, this temporary file can written here by setting "setenv TMPDIR xxx".

Image Quality

  • multi-pixel filtering: Globals->Use Multi Pixel Filtering. This will produce very high quality when dealing with thin geometries or thin highlights.

  • non-square textures: in some situations in which non-square textures are being used and the image quality does not look as good as needed, try resizing (with proper filtering) the image to a base-2 square resolution - by base-2, I mean 1,2,4,8,16,32,64,128,256,512,1024,2048,etc.

  • higher order texture filters: Texture->Filter Type. For noisy file textures, the default mipmap filter type may be insufficient in terms of anti-aliasing spatially and temporally. Setting the filter type to quadratic usually provides much better quality, though at a small increase in performance cost. Avoid increasing the shading samples just because of the texture aliasing.

  • avoid Phong for skinny highlights: Anti-aliasing phong highlights are very tricky, because they are hard highlights. Blinn highlights are much softer and realistic. They are also much better when facing skinny or noisy highlights.

  • avoid user error aliasing:

* check composite render is not turned on

* check that the edge-anti-aliasing is turned on at HIGHEST QUALITY

* check that your textures do not have their filters turned to OFF

How to control render globals' performance + memory options for raytracing:

  • subdivision Power: this determines the (x,y,z) resolutions of the voxels.

  • recursion Depth: with a fixed resolution for voxels, it is possible that a voxel may contain many triangles, thus raytracing will be very slow if this voxel is hit, because the ray will need to intersect against many triangles. We recommend that this stay at 2, because there is a trade-off of voxel traversal time vs. triangle intersection time. Larger does not mean better. Larger also means more memory used (by the voxels).

  • leaf Primitives: in the above description, we need to determine what is considered to be "many triangles". This attribute determines the number of triangles in a voxel before we recursively create voxels.

  • Render globals->performance + memory options->file caching is turned on, additional cached information for tessellation and voxel pointers will be done to make sure we don't explode memory usage too much. I.e., a not-too-often used voxel and its tessellations will be purged onto disk until needed later. This is done so that other more often visited voxels and tessellations will be handy for raytracing to deal with in RAM quickly. If there is available memory to be used for raytracing, increasing the render globals' maximumMemory memory value can improve the speed of raytracing, because it will do less disk caching.

  • selective raytracing: as mentioned in the FAQ, it is possible that a surface does not need to be tagged as visible in reflections, visible in refractions, or shadow casting. When a surface is not turned on for any of the above 3 attributes, that surface is not added to the voxel structure.

  • linear transparency: if your index of refraction is 1.0, there is no reason for one to use raytracing for refractions. To avoid raytracing expenses, it is best to not use raytraced refractions.

  • if you can afford the memory: to avoid lots of disk caching, increase the maximum memory value and you should get a big improvement in performance. This can be done in the command line with "-mm ###", where ### is the number of megs to be used as the memory limit.

Keywords: Info, maya, render, optimise

-- MattEstela? - 29 May 2003

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
Main.MayaOptimisingRenders moved from Main.OptimisingRenders on 31 May 2003 - 01:13 by MattEstela
Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback