# Introduction to MayaHydra
The _Hydra for Maya_ project builds on the foundation of the Maya to Hydra (MtoH) plugin, contributed by Luma Pictures. Our goal is to extend this plugin to cover a wider array of use cases, prioritizing performance, robustness, and customizability.
The MayaHydra code is a Maya plugin using the MRenderOverride API. This API binds the plugin to a Maya viewport window, adds an entry in the Renderer menu to activate the plugin, and allows control of overall viewport rendering.
### Maya API Additions
We have begun adding new APIs to Maya to provide efficient access to renderable viewport data. The experimental MDataServerOperation gives an MRenderOverride plugin like MayaHydra access to Viewport 2.0's internal copy of renderable scene data. MayaHydra can use this as an option to render data provided by Viewport 2.0, instead of having to reconstruct internal Maya features to match viewport appearance and the behavior of Maya features.
### Data Access and Interpretation
Maya contains many different object types and features that affect how they render. To try to replicate that rendering, a plugin viewport would have to access the raw data of each object through node attributes and to reimplement the display logic. This makes supporting a wide range of object types and features too costly.
Instead of always extracting state from the raw attributes of a Maya node, the MDataServerOperation API provides an abstract view of things to be rendered via the (pre-existing) MRenderItem API. A render item is similar to a Hydra RPrim and roughly corresponds to a single traditional 3D "draw call" in OpenGL or DirectX. It is an association of geometry buffers with an index buffer, a primitive type (triangles, lines, points), a shader, and shader parameters (transform matrices, colors, textures, etc.) The MRenderItem wraps an internal renderable object that VP2 uses internally to draw.
One effect of the MRenderItem approach is that the plugin viewport no longer needs to care about the details of most Maya node types. For something like a Maya joint node, the original attribute approach involved writing an adapter class that manages all the attributes for the type and its interactions with other DAG objects. In the MRenderItem approach, the plugin doesn't necessarily need any joint-specific code. Instead, it receives an MRenderItem with the line geometry and color information, which is enough to render and support selection. In this way, we leverage the existing Maya viewport code that implements the "business logic" that decides what a joint looks like, while delegating rendering control to the Hydra framework. Here the Maya internal viewport code functions as a data source, serving primitives to Hydra.
### MRenderItem Method Can be Optional
This file has been truncated. show original
