The attachment model for DG nodes or DAG objects is supported by the registration interface MDrawRegistry. The attachment model for render loop overrides is discussed in greater detail in the section: 3.6 Render Loop Overrides.

For draw, shader, shading node, geometry and sub-scene overrides, the association is implicitly provided via the use of node classification strings. Override classification and Maya node/object classification matching forms this implicit link. The matching is performed hierarchically from broad to specific via the usage of “sub-classifications.”

The format required of a classification string is as follows:

drawdb/<object classification>/[<sub-classification>]/<override classification>”

Figure 35: For each override type the classification matches any objects or nodes specified in the classification.

Figure 36: Example demonstrating that, depending on how on how specific the classification is, different matches results. The “drawdb/geometry/parametricSurface/B-spline” DAG object classification matches more closely to the override with the identical classification string, rather than the more generic “drawdb/geometry/parametricSurface” string. The classification with the closest match is used.

The getClassification command documentation contains a list of classifications recognized by Viewport 2.0.

Draw a custom object that performs lighting in Viewport 2.0

For dag objects that wish to contribute lighting as well as have custom drawing, it is possible to have two “drawdb” classifications: one that starts with “light” and one that starts with “geometry”. This is shown with the “drawdb/geometry/light/myLight” classification on the node and corresponding geometry override, as well as a “light” and “drawdb/light/directionalLight” classification.

A simple example is given in the apiDirectionalLightShape plug-in example, which draws the following custom geometry (in blue) as compared to the default internal drawing of a directional light.

Only classifications for draw and geometry overrides may be registered along with “drawdb/light”. Overrides such as “drawdb/subscene”, for example, are not allowed.

In order for the override of a plug-in node to represent the drawing of a light, the “drawdb/geometry/light” classification string should be used when registering the override; for example, a classification string such as “drawdb/geometry/light/myLight” could be used. Support for display type filters becomes available when this classification is used, such that the drawing of these plug-in nodes are filtered when lights are filtered.

Register transform node plug-ins

Plug-in writers should be aware that, in order for a plug-in transform to be recognized in Viewport 2.0, the appropriate classification string drawdb/geometry/transform must be added when registering the transform. This must be done so that:

For example, for the rockingTransform plug-in, the code is as follows:

// Classify the node as a transform.  This causes Viewport
// 2.0 to treat the node the same way it treats a regular
// transform node.
const MString classification = "drawdb/geometry/transform";
status = plugin.registerTransform("rockingTransform", 								

If this is not done, then registerTransform() automatically adds the drawdb/geometry/transform classification if no other drawdb classification is specified.

Registering Display Filters

New display filter types can be added for plug-in objects via a registration interface. If the classification string used matches the classification string used for registering a draw override, the override may be filtered out when visibility checking is performed. The UI name for the filter appears as an option for display filter interfaces for 3d viewports and batch rendering.

MFnPlugin::registerDisplayFilter() is the interface to register a new display filter type. The gpuCache SDK plug-in contains code which demonstrates its usage.