Scene Module (SCENE)

The Scene module provides a layer on top of the DB module. Its main purpose is to manage storage of the scene in memory, and to provide functions for global operations on the scene. It is used by all modules that deal with scene data, specifically for the API module. Scene also provides functions to convert the stored scene to a renderable representation that is accepted by other modules such as renderers, walkthrough viewers, or wireframe display functions, and uses the GAP module (the tessellator) for this purpose. In a dataflow sense, the Scene module sits in the pipeline between the translators and the renderer/viewer.

From Scene's point of view, a wireframe or hardware-shaded viewer is just another kind of renderer; the term ``renderer'' is used synonymously with ``viewer'' throughout the Scene documentation. The Scene module accommodates a wide range of different renderers; the render options data type provides fields sufficient for sophisticated ray tracers as well as simple hardware shading renderers. The Scene modules makes no assumptions about rendering-related data other than providing reasonable defaults; the actual interpretation of the data, and which parts of the data are used, depends on the renderer.

Scene geometry data flow

The bidirectional arrow from the translator to the DB module represents creating, editing, and deleting operations on the scene database. Some translators such as the .mi translator use the high-level API module to simplify scene creation. The Scene module manages this flow of data to keep track of changes. All other arrows represent the preprocessing stage managed by Scene that converts the source geometry created by the translator to a renderable representation accepted by the renderer. Note that the renderer may also access non-geometry data such as materials directly in DB without involving the Scene module; this diagram only shows geometry dataflow. There is also a postprocessing stage for cleanup after rendering completes.

Specifically, the Scene module has three main functions:

Group 1 High-level database element allocation. Unlike DB, database elements are allocated by type, and Scene provides defaults for each parameter. A unified set of operations is defined for each element type. Only Scene may use the allocation functions of DB directly; this ensures backwards-compatible changes to database data types and complete control over byte order conversions on the network.
Group 2 Management of the scene DAG. All database elements that form the scene in the database are linked using tag references (a tag is a network-transparent ID number similar to a pointer maintained by DB). The Scene module provides functions to build and modify the DAG, either sequentially or while rendering. Modifications to existing scenes, possibly after they have been rendered already, are called incremental changes, as opposed to recreating the next frame to be rendered from scratch. Specifically:
- Sequential incremental changes between renders are supported with dirty flags for certain element types that tell the preprocessing stage (see below) what to redo.
- Certain element types that form the DAG topology (instances, leaf instances, groups, functions, objects, lights, and cameras) have reference counts that are used to delete the element when the last link to it is broken.
Group 3 Management of scene preprocessing. Scene keeps track of modification operations and provides a scene preprocessing function that converts the scene DAG into a renderable representation. This includes
- forwarding modified database elements to other hosts on the network,
- instancing including multiple instancing,
- inheritance of material parameters stored in instances using a custom inheritance or traversal function provided by the caller,
- tessellation or re-tessellation of source geometry into triangle boxes (the Scene module attempts to re-use tessellated geometry whenever possible to reduce the amount of processing to be done from one frame to the next),
- calling geometry shader functions for dynamically creating source geometry, and
- collection of renderable geometry.

The term instancing indicates that geometric objects and lights can be stored once, but appear multiple times in the rendered scene. This is implemented by storing the scene as a hierarchy of instances that refer subtrees, geometry, or lights. If multiple instances refer the same element, directly or indirectly, that element is said to be instanced multiple times. When traversing the hierarchy, the Scene module supports programmable inheritance of shader parameters such that higher levels of the hierarchy can pass shading parameters down to lower levels. The exact method of inheriting information is programmable, using an inheritance function that combines the parent parameter block and the child parameter. The parameters being inherited this way follow the same rules as standard shader parameters. Shaders have access to both their standard static parameters, and to the inherited parameters.

mental ray supports traversal functions that replace older inheritance functions. Both are basically equivalent, except that traversal functions have access to the entire instance being inherited, and also receive a traversal graph history list from the root group down to the current instance. This gives the function more control, for example over material inheritance. The inh_is_traversal flag in the options block controls whether the function is an inheritance function or a traversal function.