Using Map Generators

How to Control the Generation of Pre-Computed Maps

Using Map Generators is straightforward, if you have an understanding of the underlying workflow. Basically, map generators are used to create pre-computed maps.  After pre-computed maps are generated as a pre-pass, they can be referenced by shaders during the final pass. 

Map Generator Workflow 

Here's a simple recipe for using a Map Generator.

  1. Create a Map Generator appearance in Slim and attach it to a camera, coordinate system, or object.

  2. Configure the Map Generator by choosing maptype, frequency, etc.

  3. Reference the pre-computed map. Identify all shaders that want to use the map and enter the appropriate syntax, which identifies the computed map.


  1. Map generators must be enabled and configured as outlined above.
  2. A map generator will generate a map for every object it is attached to. 
  3. Map generators do not appear in renders. They only pre- compute maps.
  4. For more information about Map Generator parameters see: Map Generators.


Creating a Map Generator

Map Generators are used to create custom pre-passes. Different types of Map Generators can be used to create different types of passes. Map generators can be attached to cameras, coordinate systems, any Maya object, or any Maya light. Map generators generate maps from objects they're attached to. Using a shader to reference a pre-computed map provides uncanny control over lighting, reflections, and shadows in a scene, as all of these elements can be directed creatively, free of the constraints of physically based lighting.

Creating a Map Generator in Slim:

A map generator can be created in Slim from the Create Appearance menu, as shown below. Once created, a map generator can be attached to an object and then appropriately configured for the scene. 

The Slim Map Generator Menu


Configuring a Map Generator

A map generator must be properly configured. Some of the most crucial settings are outlined below. These attributes control various details about how a map is generated:

Context - Specifies the value of the CONTEXT global during the rendering of this element. The value of the CONTEXT global can be consulted by Adaptor appearances to choose context-specific appearance attachment.

Frequency - you can choose to generate a map: Never, Every Frame, or Once Per Job.

Camera Name - the name of the camera to compute the map from. When you specify $OBJNAME, Slim requests a map for every object the Map Generator is attached to.

Objects in Map - the objects that participate in the map calculations. When this is left empty, all object participate. Enter a Maya set enter to define which objects will appear in the map. Note that preceding a Maya set with a "!" will exclude that set, as in !MayaSet.

Laziness - controls when to recalculate a map. Options are: Off, On, and Use Global. When set to Off a new map is calculated each time it's needed. When set to On, MTOR only calculates the map if it's not already present. This setting is useful when you're in a tight interactive loop. When set to Use Global, we simply use the Global setting specified in the Render Globals dialog.

Far - the far clipping plane. When set to 0 we use global defaults.

Map Resolution - the resolution of your map, measured in pixels. Maps are always square, but might compensate for the contents via the screen window.

Image Type - Choose Texture if you wish to use the resulting image as a texture map. It will be automatically converted into a texture file by alfred. Choose Final Image if you don't need to access the image in your shaders.

Strategies for Configuration


To turn on computed maps, map generation must be enabled. With the shader open in the appearance editor, change the Frequency parameter from Never to Every Frame. Now the shader will generate a computed map for every frame rendered in the scene.

Sometimes you may not need to recompute a map every frame. In these cases the Frequency can be set to Once Per Job. There are a few common cases where a single computed map is sufficient to provide a desired effect for an animation. For example, imagine you've got a static scene of which you're doing a camera-flyby. In this case, neither your environment maps nor your shadow maps would need to be computed every frame (but your reflections would). MTOR allows you to specify on a per-map basis whether your map requires computing Every Frame or Once Per Job. MTOR causes all static maps to be computed at the Reference Frame during Job Preflight. MTOR also allows you to globally disable the calculation of and reference to computed maps or lazily compute them during scene debugging or preview.

Defining Membership

Often, you'll find it useful to control membership in computed maps, selectively picking which objects appear in the pre-computed map. For example, you want to use reflection mapping but have the problem that your mirror is in the middle of the scene. Without guidance, MTOR will put all the objects in the reflection map (including the mirror!). This will not give you the right result. You'd really like MTOR to consider only the objects you want to appear in the reflection — the objects in front of the mirror.

There are two ways to define membership:

  1. Per-Object Modeling Attributes - Most modeling systems have a set of rendering attributes that you can control on a per-object basis. MTOR uses these attributes where they exist. For example, Maya supports Casts Shadows and Visible in Reflections attributes. In the reflection example above it would be very easy to only enable Visible in Reflections for the objects in front. This technique is often quite simple but isn't as powerful as method #2 because it will affect all reflection and environment maps or all shadowmaps. Thus, if you had two mirrors in your scene, it would be unlikely that both mirrors would reflect the same objects.
  2. Named Sets - Again, most modeling systems support the notion of grouping arbitrary collections of objects into a named set. The important aspect of this idea is that set membership is non-exclusive. This means that you can put an object into any number of sets. Once you've decided which objects you want to participate in the calculation of a map, you just need to create a Maya set and then enter its name in the parameter "Objects In Map".
Optimizing Membership for Efficient Rendering

A crafty selection of which objects are included in a computed map can help to dramatically optimize a scene for rendering. Again, through simple analysis you may be able to determine that many objects simply don't contribute much to the final image (through the computed map). Eliminating these objects from the computation can often have significant impact on the rendering time. The most common optimization is to eliminate floors (and often walls and ceilings) from shadowmap calculations. Since they don't usually cast shadows on objects in the scene, it's a waste of energy to consider them in shadow calculation. Note that eliminating objects during the calculation of maps doesn't prevent them from "receiving" the information in the final image. Thus, the floor will still display objects' shadows even though it doesn't cast its own.

Referencing a Pre-Computed Map

So the map is being generated. The next step is to create shaders that will reference that map. You must tell shaders in Slim to refer to a particular computed map. Generating a computed map is not effective unless it is then referenced by a shader. Here is an example of a shadow referencing a shadow map:

Referencing a pre-computed map is accomplished via Slim's texture conversion menu, as shown below. Simply pick the appropriate selection from the "Refer To" menu, and the appropriate syntax will be provided. (Alternatively, the syntax could be entered by hand.) Keep in mind that the $OBJNAME variable works as long as the map generator is attached to the same object that the referring shader is attached to. In certain cases the name of the texture must be *explicitly* stated, by typing in or browsing for the filename. 

Referencing the Pre-Computed Map

Automatic Optimizing of Computed Maps

MTOR automatically determines optimized shading & lighting conditions based on the type of map, which speeds up the computation of computed maps. The idea here is to include only the subset of rendering information that is needed to compute the desired results. For example, you don't need to compute the marble surface on a coffee table in order to know where its shadow falls. MTOR uses the following techniques to optimize the generation of pre-computed maps:




Pixar Animation Studios
(510) 752-3000 (voice)   (510) 752-3151 (fax)
Copyright© 1996- Pixar. All rights reserved.
RenderMan™ is a registered trademark of Pixar.