Multiple Draw APIs

The API is presented in a draw API agnostic for the most part. If a plug-in is writing for entry points which are draw API specific then it should return the API that it is being used for. The interface supportedDrawAPIs() is provided for all relevant entry points.

If the device API that is returned does not include the current device API on which Viewport 2.0 is running; for example, if VP2 is running on OpenGL Core Profile mode, but supportedDrawAPIs() does not return MHWRender::kOpenGLCoreProfile, then a warning similar to the following appears:

Error: line 0: Failed to create evaluator for "drawdb/geometry/apiMesh" classification because the current drawing API isn't supported.

It is the responsibility of the plug-in to set up any dependent draw API libraries or interfaces. The SDK ships with specific versions of libraries for each supported draw API. Current dependent libraries are CgFx, DirectX11 and a pre-compiled DX11 effect runtime library. As the source code ships with the DirectX SDK, the pre-compiled DX11 effect library can be recompiled by plug-in writers and linked explicitly to their own plug-in. Current library versions are listed as part of the shipping resource notes.

Some notable draw API caveats are listed below. These are restrictions are imposed by the draw API libraries rather than a restriction in the Maya API.

When using the texture or target manager provided, not all formats are available for all draw APIs. Refer to externally published documentation provided with each API.
Textures accessed from the texture manager use the upper-left corner as the origin. Shaders should be written with the appropriate texture coordinate to perform a vertical flip as necessary.
Cube map texture face orientation is draw API specific.
Stock shaders provided by the shader manager hide the details of differences between shading languages. When not using stock shaders, the plug-in writer will need to write code which is specific to that shading language. For example, handling differences in vector / matrix multiplication between Cg and HLSL.
User-created shader fragments registered with MFragmentManager are not required to define implementations for both OpenGL (Cg) and DirectX (HLSL). However, if both implementations are defined, it is up to the author to handle any differences between the two (such as texture access or matrix math). In some cases, this may even require completely different fragments to be written, requiring the classes that use the fragments to choose the correct fragment for the currently active device.
It is quite possible that some geometry requirements specified from an MPxShaderNode are not fulfilled. In this case the plug-in will need to handle this situation. In particular, noting how DirectX is less tolerant to vertex stream mismatches than OpenGL.