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