New API changes for Maya 2017 updates 2

Some of you may already know about this, but I think I still need to emphasize it again here. In the past, we used to have Service Packs and Extensions after the Maya main release. But starting from Maya 2017, we will not provide Service Packs or Extensions any more, instead, will use Maya Updates to maintain and update the software regularly, providing new features, and quicker fixes to customer issues.

For our plugin developers, one important thing you should be aware of is that the Maya API binary compatibility will not be broken in any 2017 updates, however, the API may be extended to enable new features.

So far, Maya 2017 released 2 updates, if you want to know the features/improvement that have been included in these 2 updates, please check the following page:

• What’s New in Maya 2017 Update 1
• What’s New in Maya 2017 Update 2

If you want to know where to download and how to install these updates, please refer my previous blog of “Recent new releases (Nov. 2016)”.

OK, now let’s focus on the API changes in Maya 2017 update 2, here are the details:

• Shading
  

  Let’s talk about the new added method MShaderInstance::writeEffectSourceToFile(), the method is easy to understand, it’s used to write the final effect source to a file so you can perform validation on custom shader fragments on all device APIs. It’s used for debugging to see how fragments are turned into the final effect for the current drawing API. Note that the effect will not be written if the effect is not generated from shader fragments or any of the shader fragments is marked as hidden.

• Lighting
  

  Another improvement is about “Lighting” support, and I want to talk more and highlight it here. Actually, the “Lighting” feature is continuously improved since it was first supported from Maya 2016 Extension 2. Let’s see the history of evolvement:

  Maya 2016 Extension 2:

  Developer can create a plug-in shape which is classified generally as a light, to be recognized as a lighting contributor, the classfication string “light” is required, and the only possible sub-classifications are those available for internal Maya lights, they include “ambientLight”, “pointLight”, “directionalLight”, “spotlight” and “volumeLight”, the possible classification for your light shape should be one of the following:

  • "light:drawdb/light/ambientLight".
  • "light:drawdb/light/pointLight".
  • "light:drawdb/light/directionalLight".
  • "light:drawdb/light/spotlight".
  • "light:drawdb/light/volumeLight".

  The classification allows for the usage of the internal light and UI (geometry drawing) VP2 evaluators to be used. There is no explicit VP2 override class used as the internal VP2 geometry evaluator will handle drawing.

  Also, be noted that if you use the “light” classification, you must include these light attributes: intensity, color, emitDiffuse, andemitSpecular, in order for the light to behave like a Maya light.

  For the details, you can check the new added sample “apiDirectionalLightShape”, it demonstrated how to add a plug-in light, you can also refer the User Doc to see how it works with the new Light Editor.

  Maya 2017:

  The “Lighting” feature was improved, developer now can combine a custom draw override with internal Viewport 2.0 lighting support. For dag objects that wish to contribute lighting as well as have custom drawing, it is possible to have two “drawdb” classifications: one that starts with “light” and one that starts with “geometry”. The classification for the node should be something like "light:drawdb/light/directionalLight:drawdb/geometry/light/directionalLightCustom".

  Then, 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/directionalLightCustom” could be used for above sample node. My colleague Vijaya also posted a blog post which talking some about this.

  Btw, only classifications for draw and geometry overrides can be registered along with “drawdb/light”. Overrides such as “drawdb/subscene”, for example, are not allowed.

  Also, the devkit sample “apiDirectionalLightShape” is also improved to have a customized VP 2.0 override named “apiDirectionalLightShape_GeometryOverride” demonstrate the usage, it create a different drawing as the blue arrow that is shown in the following picture. You can check that sample for more details.

   

  Maya 2017 Update 2:

  There are 2 improvement for “Lighting” feature.

  The 1st one is the “Exposure” attribute for a light node. Besides the intensity, color, emitDiffuse, andemitSpecular attributes that must be included for a light node, the “Exposure” attribute is also parsed for internal light evaluation. For demonstration, the devkit sample “apiDirectionalLightShape” is updated to include this new attribute for all these light nodes.

  The 2nd improvement is about the new classification of “drawdb/light/image”. Now developer can use this new classification to register a plug-in node so that it behaves like an internal IBL (Image Based Lighting) light. I do suggest you to talk a look at this introduction doc about this new light type if you are interested. Also, the “apiDirectionalLightShape” sample is updated to include the new type of “apiImageLightShape”, if you get the new devkit for Maya 2017 update 2 which is located at Autodesk Maya App Store, you can check the implementation, it should be pretty straightforward.