API Guide > Writing a Hardware Shading Node >

# Overview of hardware shading node plug-ins

This chapter details how to create hardware shading nodes, which are used when rendering Maya's scene view. For shaders used by the Maya Software Renderer, see chapter on Writing a Software Shading Node.

A hardware shading node plug-in is written as a Maya Dependency Graph (DG) node. A basic hardware shading node contains attributes that are treated as inputs and outputs; where each shading node must have an output so that it can be connected in the Dependency Graph. Also, hardware shading node plug-ins implement virtual methods that are called to perform resource creation, deletion and drawing. These virtual methods are called when Maya detects that there is a hardware shader node plug-in attached to a piece of geometry and Hardware Shading is required. You can implement Standard OpenGL rendering, vendor extensions, pixel/vertex shaders and multi-pass shading with the hardware shading node plug-in to provide a fine level of control over Maya’s display.

Hardware shading plug-ins are supported in the Maya scene view, the scene view with High Quality Interactive shading mode, the hardware renderer and the UV Texture Editor. The types of geometry supported by these areas of Maya are as follows:

- Mesh shapes are supported in all areas
- NURBS surfaces are only supported in the scene view with High Quality shading display and the hardware renderer when using the gl interface (described next)

To develop a hardware shading node plug-in, derive from MPxHwShaderNode and implement the virtuals that are required. There are many virtual methods in the MPxHwShaderNode class. The most important virtual methods are the ones that perform binding, drawing and unbinding. These methods are key to performing resource allocation, drawing and resource de-allocation. There are two versions of these methods.

The original interface is:

    virtual MStatus bind( const MDrawRequest& request,M3dView& view );
    virtual MStatus unbind( const MDrawRequest& request, M3dView& view );
    virtual MStatus geometry( const MDrawRequest& request, M3dView& view, int prim, unsigned int writable, int indexCount, const unsigned int * indexArray, int vertexCount, const int * vertexIDs, const float * vertexArray, int normalCount,
     const float ** normalArrays, int colorCount, const float ** colorArrays, int texCoordCount, const float ** texCoordArrays);

The second interface or the gl methods are:

    virtual MStatus glBind( const MDagPath& shapePath );
    virtual MStatus glUnbind( const MDagPath& shapePath );
    virtual MStatus glGeometry( const MDagPath& shapePath, int glPrim,
        unsigned int writeMask, int indexCount, const unsigned int* indexArray,
        int vertexCount, const int * vertexIDs, const float * vertexArray,
        int normalCount, const float ** normalArrays, int colorCount,
        const float ** colorArrays, int texCoordCount, const float ** texCoordArrays);

The interfaces are quite similar when comparing parameters. The significant difference between the parameter lists is that the MDrawRequest and M3dView objects in the original interface have been replaced by MDagPath objects in the second interface. If draw information (MDrawRequest objects) are not need for your hardware shader node plug-in, then it is suggested that you implement the gl interface since more functionality is supported.

Note

By default, the bind(), geometry() and unbind() methods call the equivalent versions of the gl interface.