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>”

• drawdb : Is root string used to identify registration with the rendering database. This is always required.
• <object classification> :
  • “shader” : To be recognized as a shader, this string is required.
  • “geometry” : To be recognized as something that can draw geometry for a renderable object, this string is required.
  • “subscene“ : To be recognized as a DAG object that is evaluated with an MPxSubSceneOverride implementation, this string is required.

• <sub-classification> : This provides additional levels of classification which are useful, and in some cases, required for grouping and managing overrides. In particular, shading nodes that are used as surface shaders (connected to the Maya shading engine) must use a classification which starts with “drawdb/shader/surface/”. Sub-classification is optional for DAG overrides.

  In general, the more sub-classifications specified, the more specific the type of objects/nodes associated with a given entry point. For example, in these two examples:

  1. “drawdb/shader/surface/myLibrary/myShader”
  2. “drawdb/shader/surface/myLibrary”

  The first classification string, when used, would match fewer objects/nodes than the more-generic second string.

  For either existing or new plug-in node types, it is the responsibility of the plug-in writer to ensure that the appropriate classifications are used for both the override and for the node itself so that the correct classification string matching (association) is performed.

• <override classification> : Unique override classification. Often, this is the name of the node type the override is to be used with (if it is not used with multiple node types).

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.

• 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:
  • Local rotation axis and pivots draw.
  • Transforming the object moves any children parented under it in the DAG.

  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", 								
                                     rockingTransformNode::id, 					 				
                                     &rockingTransformNode::creator, 								
                                     &rockingTransformNode::initialize,
                                     &rockingTransformMatrix::creator,
                                     rockingTransformMatrix::id,
                                     &classification);
  

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

• 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.

 Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Please see the Autodesk Creative Commons FAQ for more information.