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.

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

Frequency

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:

• Shadow Maps
  In the normal case, no shading or lighting information is required during shadow computation. By default, simple shaders are attached to all the surfaces in a scene during shadow map generation, which substantially speeds up rendering. There are two cases in which this optimization will cause issues. First, if you have a displacement shader which displaces a surface, that shader needs to be included in the RIB file for the shadow calculation. Second, if you have a surface shader which modulates opacity, you'll also want that shader to be included. The most direct way to control this is via an Ensemble's Cast Shadows parameter. By switching "Cast Shadows" to "shade" both displacement and opacity will be taken into consideration during shadow map generation. Alternatively, MTOR will use displacement bounds and Os to detect these cases, which may be more of a hassle to setup. 
  
• Reflection Maps
  Generally, all shading and lighting information is required during reflection map generation. For this reason, reflections are computed after all shadows and environments are completed. The reflecting object shouldn't be included in the calculation of its own reflection map, otherwise the reflection will be wrong. To avoid this situation turn of that objects reflection attribute, or use a Maya set to define which objects are considered in the reflection map. If you have multiple reflection maps in your scene, you may find that using Maya sets to control which objects appear in which maps is immesurably helpful. Keep in mind the in many case reflection maps are find, but they are not physically accurate and have certain limitations. If you require accurate reflections, you might consider ray tracing.
  
• Environment Maps
  As with reflection maps, environment maps also generally require full lighting and shading effects. However, because their contents are view independent, environment maps can contain objects that display reflections of their own. In order to sort out the order of precedence of your environment maps, MTOR prioritizes them according to the location in the DAG of your scene. When traversing a DAG, MTOR descends from top to bottom, left to right. The first environments MTOR encounters are computed first, following environments can include effects of previous environments. This, of course is an arbitrary prioritization, however, armed with this information, you can reorganize your DAG according to your requirements. Environment maps can create perfectly convincing reflections in many, but not all cases. When accurate reflections are essential consider ray tracing these effects instead.