The scene override classes allow plugins to override elements of the 3d scene graph, including geometry, shaders, and other renderable elements. These classes provide new APIs to replace the old rendering code in MPxLocator, MPxSurfaceShape , MPxComponentShape, MPxHwShader, and MPxHardwareShader. User plugins can continue to derive off these existing base classes; however, you'll need to register one of the following overrides to define your custom rendering logic in the new viewport. This also means you can leave your existing rendering code in place, allowing your plugin to work simultaneously in both the old and new viewports as you transition your pipeline across. The old viewport will continue to call into the old code, and the new viewport will use the overrides defined below.
While many of the old interfaces provided raw C++ interfaces at render time, this approach does not provide the best performance, particularly when you have large numbers of plugin elements in the scene. The new overrides use the geometry data objects above to support a cached, retained mode rendering interface that more clearly separates shaders and shapes, and also allows them both to benefit from many of the performance optimizations in the new viewport (such as geometry consolidation). Having said this, there are still times where you'll want total control over what is rendered, so we still provide an immediate mode interface to succeed the interfaces provided in MPxLocator and MPxSurfaceShapeUI.
MPxDrawOverride formalizes the draw override functionality provided by the old MPxLocator class. It provides a simple interface that allows users to make arbitrary OpenGL calls whenever a specific shape type needs to be drawn by Maya. When using this interface, your plugin assumes full control over all the geometry and material resources and setup required to draw. This also means your plugin will not benefit from the resource management and resource optimizations provided by the new viewport. However for light-UI or large proxy geometry, this can still be a good approach.
Implementations of MPxDrawOverride must be registered with the MDrawRegistry class against a specific type of Maya DAG object (either plugin or standard). Registration is by classification string. This class can be used to provide drawing for plugin shapes or to completely override the draw of standard shapes like meshes or NURBS surfaces. For a DAG object type to be recognized by Viewport 2.0, it must be registered with a classification string that begins with “drawdb/geometry/” and this is the same classification string that is used to register the implementation of MPxDrawOverride. For example, the standard Maya mesh type is registered as “drawdb/geometry/mesh” and so to override the standard draw with an implementation of MPxDrawOverride one would register that implementation with the classification string “drawdb/geometry/mesh”.
This class provides very low-level access to the draw. It is necessary to manually set up all shaders and do proper state management in order to get correct drawing and to avoid corrupting the draw of other objects. A new utility class called MDrawContext has been added to assist with state management. An instance of this object is always passed into the draw call of MPxDrawOverride.
For a higher level interface to geometry, see the new MPxGeometryOverride class.
This class represents one of the larger changes from the old API. Where MPxSurfaceShapeUI gave you C++ draw control, MPxGeometryOverride is purely an interface for defining geometry and render items. All control of the actual rendering is left to the shader. By doing this, this class can work with external shaders and it can leverage performance optimization such as geometry consolidation.
MPxGeometryOverride is a high-level interface that allows the user to provide geometry buffers, index buffers and custom render items that will be used by the Viewport 2.0 system to draw a specific DAG object. Data is primarily transferred through the MGeometry class described above. Implementations of MPxGeometryOverride must be registered against the DAG object type just like MPxDrawOverride.
An implementation of MPxGeometryOverride is invoked when an associated DAG object changes. The implementation is expected to provide updated geometry buffers and indexing information which will be packed by Viewport 2.0 and stored on the graphics card (if possible). MPxGeometryOverride is only invoked when something needs updating and not on every frame.
Similar to MPxDrawOverride, MPxGeometryOverride can be used to provide geometry for either plugin shapes or to override the behaviour of standard Maya shapes. The biggest advantage to using this higher level class is that objects which use it will automatically work with any shader supported by Viewport 2.0. This class also requires no direct OpenGL knowledge as it is device independent.
MPxShaderOverride allows the user to create a custom override for associating a "full shading effect" with a shading node (custom or standard) in Maya. Its primary use is for associating hardware effects with pre-existing plugin shaders.
A "full shading effect" defines the complete shading and lighting involved to render a given object. Input resources for shading such as geometry, textures, and lights are defined and bound to the shading effect via the override as required. The override is fully responsible for these tasks. As an example, for hardware shading, this can be thought of as implementing a CgFx or HLSL effect file renderer which can use the resources defined within a Maya scene.
Like MPxDrawOverride, this is a low-level class. Any object using an instance of the associated shader to draw will trigger the MPxShaderOverride draw callback at draw time. The implementation is responsible for setting up all shading information. It can then either query the geometry itself through the MDrawContext to do all binding and drawing; or, it can make a call back into Maya to allow Viewport 2.0 to handle the draw using the current state.
Like the other two new interfaces, MPxShaderOverride must be registered with MDrawRegistry using a classification string. This means it can be associated with either a plugin shader type or with an existing Maya shader type. Viewport 2.0 shader classification strings must begin with “drawdb/shader/” (for example, the standard lambert is “drawdb/shader/surface/lambert”).