The FHShader node uses OGSFX files to render geometry with VP2. On export these files are parsed into individual files of the type of vertex and fragment shaders (glsl) used by the game engine. The goal was to create a node that was as WYSIWYG as possible. Minimizing the difference between how something appears in the game and while it is being designed is key to making what that the player sees as cool as possible.

Writing a Maya node plugin for the first time was daunting but as usual, detailed logging and careful debugging saved the day. It was exceedingly convenient to be able to map out the life cycle of a node via call stacks and text files after Maya crashed or was stalled because of something I broke.

I didn’t expect to have to write code for things like the UV Editor and sample thumbnail but I am sure the extra flexibility will come in handy in some future iteration.

This is where the design and functionality of Tool1 is being developed and tested. The exporter and all of the tools should be as seamless as possible, so integrating well with Maya and with the manifest are both high priorities. I decided to use .NET controls instead of Maya widgets so that all of the tools can reuse the same UI and share more code.

The goal is to convey as much information as possible with the design (colors, fonts, size, etc) so that it feels intuitive as soon as possible. For example the border around an asset becomes light green when it is edited, a darker shade of green when it is saved to the local manifest, and the darkest green when it is saved to the manifest of record.

There is a search feature that allows looking for searching for text in the UI, both in the labels and the editable fields. This feature is something that has become expected when using a computer, no matter what the application is, and when it is missing it is sorely missed.