Dev Blog

One thing that has been lax recently is the linux build of Catharsis. I do most of my development on Windows with Visual Studio (who doesn’t) so it’s easy to understand why this has slipped. This has been rectified.

In the beginning there were Makefiles. Writing them sucked. The time and effort required to write Makefiles to build large projects was ridiculous. Then, there was scons, and times were better. However, scons got increasingly sluggish the larger the project became. In addition, scons build files were Python scripts. “The power of Python in a build file,” they said. Soon I found myself writing long, esoteric build scripts that used fancy Python code simply because I could. I now know that this power is unnecessary and ultimately confusing. What was needed was a small set of well structured commands specific to building things. At last, there was cmake.

Tony had heard a lot of praise for cmake and during the holiday I was able to verify that cmake is infact great. Cmake is both simpler and faster than scons. It also does a lot of things you’d expect to be done by default by any modern build system: dependency checking, building in a seperate directory, etc. Perhaps the coolest feature is that, instead of being a build system in and of itself, cmake produces platform specific build files. I haven’t tried the build files produced for Visual C++ yet, but the prospect of having builds for all platforms specified by one set of files is exciting.

At our last Stolen Notebook team meeting I described the workings of snmaterial and it’s seperated UI system. Denrei immediately asked if I had built snmaterial into Maya. An excellent question. I said no, but I wondered why I hadn’t.

Integrating a scriptable command line tool into your content creation tool is simple. If your content creation tool has a scripting language (most do) and can execute system commands, you’re all set.

At Stolen Notebook we use Maya for content creation. Maya’s scripting language, MEL, can be used to do a variety of things, not least of which is UI scripting. After getting acclimated to MEL’s syntax and UI system I had created a MEL UI interface for snmaterial directly in Maya. The MEL UI interface for snmaterial looks similar to the python interface.

Creating the UI script in Maya allows direct access to a few useful Maya commands that can be run on the current scene. Most importantly, I can export the current scene to Collada, a feat otherwise impossible without having to run a batch mode of Maya or compile the Maya API into the tool itself. The Material Exporter is accessible from the ‘Catharsis’ menu which is created when our custom Maya plugin is loaded. On export the script does the following:

• Exports the scene to a temporary collada file
• Generates snmaterial system command
• Runs the snmaterial command on the collada file

Chalk up another victory for command line tools.

I thought it might be interesting to discuss some design considerations of Stolen Notebook Tools.

Goals
One of the most important things to keep in mind when making tools is tool automation. Getting all assets from one end of the asset pipeline to the other with a single command is not only cool, it’s a massive time savings. Tools need to be easy to run from scripts. With scriptable tools it becomes very easy to tie tools together into a pipeline, or run a tool on an entire directory of files, etc.

While tools need to be accessible to scripting, they also need to be easy to for people to use. If a user is going to use a tool directly it must have a UI. Users are more comfortable using a tool with a UI and user error can be reduced by using well known interfaces such as file browsing. Further, a tool with a well designed UI can make the functionality of the tool much more understandable.

So, how does one create a tool that is accessible for scripting yet has a fantastic UI? By breaking the tool into two parts:

1. A command line program containing the tool’s functionality
2. A GUI program that generates calls to the tool executable

This structure achieves of all my goals. A tool can be used in a script by executing the command with arguments. The tool also has a nice interface for users.

An example is in order.

SN Material
SN Material exports materials contained in a collada file to Catharsis materials. It also copies all data files (textures, shaders, etc) used by a material into the proper location in the catharsis directory.

The command line interface for SN Material has the following parameters:

-r The Catharsis root directory
-m The module (subdirectory Catharsis root) to export into
-f The Collada file to export materials from
-n The name of the material to export. If this is not present, all materials are exported.

This tool might be run with:

snmaterial -f example.dae -r “f:/catharsis” -m “test”

This exports all materials in example.dae and copies all material data files to the module ‘test’ in f:/catharsis.

A script can easily assemble an snmaterial command. It would be a simple task to create a script that would export all materials from all collada files in a directory. More complicated functionality is not difficult.

In fact, the UI interface is just a script. This script creates a nice interface for the tool, assembling arguments to the command line tool and executing it.

I use Python for scripting and wxPython for creating GUIs. Although, any scripting language and widget library can be used since the UI is only bound to the tool through text commands. The previous command looks like this in the SN Material GUI.

As can be seen, this UI is much easier to understand than the command line tool. The user can just run the UI for the tool and will understand the tool much more quickly without having to lookup and memorize command line parameters and flags.

An unexpected benefit of this design is that I can modify and recompile the underlying tool while the UI is still running. While working on SN Material I just leave the UI open, recompile snmaterial.exe and test the exporter with a click.