No off the shelf 3d application does exactly what you need it to do for a project, but that doesn't mean custom editors need to be created from scratch. Fortunately most have great scripting capabilities to extend core functionality and allow the creation of custom project specific tools.
I've been writing Autodesk MAYA MEL scripts for about 15 years now to help streamline workflows, as well as to do tedious tasks such as data integrity checks. I'm also very passionate about user friendliness. Often a great tool is let down by being as tedious and repetitive to set up as the task it solves. I spend about as much time designing the UI and workflow of the tool as I do writing the underlying code.
Where possible I keep the number of setup parameters to a minimum, and create ready made preset buttons for the most common values (though I always leave the option to define values manually for those rare occasions a non-standard value is required). I also try to leverage the benefits from a clean scene hierarchy, creating a positive feedback loop with the tools that encourages assets to be kept neat and structured.
Little things like detecting selected assets, rather than having to manually assign them to a field in the tool AI, may only shave a few seconds off each use but quickly becomes irritating when having to do more than a couple of times in a row. Similarly, seemingly unimportant tricks like saving the current object selection list to restore it again after the script has run makes a huge difference. Often the user will want to run the script again on all (or most) of the same assets, or hide the assets from view. Keeping them selected allows the user to decide, especially if it took some time to find the exact objects in the scene in the first place. It also allows for several scripts to be run on the same assets one after the other, which is often the case.
Finally, I like to make scripts as useful as possible. Often this is not the case, as some problems are one-off fixes. More complex tasks tend to only work with a very narrow set of initial parameters. Where possible, I like to break down complex tasks into more generic ones that can be used on their own. Often I take several of these separate routines and create an additional button to run them one after another in cases where I find I'm tending to hit the same sequence of buttons without any intervening adjustments to the scene.
Most of the bread an butter scripts require a minimal UI, if any at all (my MAYA shelves can end up with several rows of such scripts). But here are a selection of some of the more interesting variety of tools I have created for various titles (that don't reveal proprietary information).
Generate golf course disk from template splines (MEL)
One of the more interesting challenges working on the Tiger Woods golf game was trying to figure out a good method for the creation of user/custom generated golf courses. While a relatively simple task at first glance, it's actually quite a tricky problem made worse by the hand optimizations, and graphic tricks required. In addition, the input had to me relatively simple (certainly much simpler that the labor intensive hand crafting of licenced courses).
I initially started trying to solve the problem with Houdini (unfortunately I don't have a copy of the tool to grab screenshots) as the ability to convert 2d images into 3d geometry, coupled with the great realtime visualization of changes to values upstream in the graph, would be a good wysiwyg environment to work in. While the 2d to 3d data extraction worked great, the boolean tools were less than robust for my liking and more often than not generated broken meshes. In addition, the realtime interaction became more laggy as more features and complexity were added. In an experienced Houdini experts hands however, I'm sure it could have worked.
But I'd always had suspicions that MAYA could do a lot of asset creation that we were considering Houdini for, and that realtime interaction was nice but not essential. So I broke down the problem into defining the bare minimum amount of input data required to create a mesh for the terrain portion of a golf hole. Nicely segmented splines of various resolutions seemed like the way to go, but I quickly decided that the resolution of the splines may need to change and that it wasn't something the user shouldn't have to worry about.
So instead the user creates some base splines and names them appropriately (or clicks a button to generate a generic set). The script makes copies and rebuilds the curves using preset resolution information for each terrain type, as well as creating additional curves either side of the terrain junctions. Then the splines are lofted in a specific order to create radial blend or regular gridded meshes. Changes could either be made to these regenerated curves (for finer control) or to the original guide splines and the mesh regenerated from scratch again with a single button press.
There are certain constraints of course. Terrain types cannot overlap, and 2 kinds of bunkers, water or teebox splines were required depending on where they would lie on the rough or fairways. The terrain is also flat, but was always planned as a post-mesh creation pass. Undercuts and tunnels would be hand carved by an artist if needed. Trees and shrubs could be randomly placed using a guide mesh to define areas to populate.
Development stopped with the cancellation of Tiger Online game, which is why the UI is so convoluted. Sections had been organized into collapsible areas, the next step would be to have collapsed some by default before finally disabling or removing completely.
Here are some of the tools we used on TWO (Tiger Woods Online) using the Unity3D engine. Because we wanted to support netbooks as the low end specifications, we ported over the Wii assets rather than the GEN4 ones (although we ended up modifying them, adding GEN4 assets where needed as well as original geometry too).
Draw calls were very important, as was various import requirements for different assets, so a lot of pre-proccessing of assets needed to be done before we could do an initial import into Unity3D. The master file needed to be separated into files that required collision or not, as well as 1 or 2 uv sets. In addition, to help with draw calls, the meshes were split based on materials (and meshes using the same material combined) .
At the start this was all done by hand and was 3-4 weeks of work for one artist. It didn't help that a course comprised of 18 separate environments, I got very good at work estimates by multiplying any task by 18. After a few courses were converted, I had enough information to try and create a solution using MEL. There were a few problems however, one being that the source Wii files were of various ages (and inconsistent at best).
So I broke the task down into 12 parts (12 steps as I would later joke), each one allowing for the user to save progress and do some hand tweaking before moving on to the next step. Courses were now ready for import in 2 days rather than 4 weeks.
To support the low end computers, we needed 2-poly (X cards) tree cards to replace the 3d tree meshes. However, the collision had to remain identical (otherwise people could alter the game by changing graphic quality) so the visual tree card had to still match the 3d mesh very closely. The tree card tool I wrote created 2 polygons to match the front and side dimensions of each tree as well as UV the mesh and render out a tree texture. We subsequently used Unity3D to render out the actual textures (so the art would match the rest of the game) but it got us most of the way there.
All in all, the scripts I wrote cut a 14-16 week process at the start down to 5 weeks, 3 of which were actually for polish and upgrades. By the end of the project,when we were about 6 months ahead of delivery schedule we were averaging processing, converting AND improving a golf hole in 12 hours each on average.
TWOnline environment and pipeline tools (MEL)
 Course creator UI |  Layout splines to guide mesh generation |
|---|---|
 Generated mesh from splines |  Shaded view of generated mesh with automatically assigned placeholder materials |
 Close up of the green and fairway |
 |  |
|---|
Photo reference tool (MEL)
 |
|---|
The toughest golf course to create for the Tiger Woods game was Augusta, not because of any inherent technical difficulties in creating a 3d version of the course but due to the demands of the owners of the actual course itself. But it was refreshing to deal with people who didn't just critique work but knew exactly what was wrong (where and why) and could supply reference.
Getting the correct skyline was especially important, even if we couldn't place each and every tree in the exact spot on the actual course. The PS3/Xbox360 had done a lot of this work already, unfortunately our game (Tiger Woods PC 13) was not based off those assets (nor had the power to use them) so we had to use multiple techniques to help match reality.
One of these was a script I wrote to allow a basic camera to be set up, with a photo reference overlay, that wouldn't interfere with normal 3d camera used when editing the scene. While a relatively simple script, it helped enormously to get the right look and feel of the more important areas of the course.
Some typical MADDEN tools I wrote to deal with daily houskeeping and to fix common data and hierarchy naming problems.
The Load Stadium script began life as a simple script that parsed the stadium source folder (later, 2 different folders) and dynamically created a UI with one-click buttons to load the named stadium into MAYA.
While navigating to individual files is hardly difficult, more often work would require doing a sweep of several stadiums one after the other. I tweaked the script to allow stadium buttons to be collapsed/hidden as a handy way of marking off the work done. Later I added a check to see if the file was read only, as a warning to check the file out (and have the latest version) before loading and editing. Checked out files also had brighter buttons than read only ones.
Finally I did a filesize check, not of the source mesh but of the exported game asset. This allowed the user to keep tabs on how much memory they had to play with, and advanced warning that memory may be getting tight. The button colors were also adjusted to tint from green to red as another visual way of keeping track of memory.
 |
|---|
Madden environment and pipeline tools (MEL)
This is a good example of a script I wrote to turn a tedious task into a quick and easy one. While rare, occasionally a player in MADDEN runs though one of the stadium walls at the edge of the field. None of the stadiums have (or need) collision, as all the important interactions for the game happen on the field. Still, in the neverending quest to improve the game, we considered adding collision to the edgewalls to help stop this happening.
Rather than just extract a copy of the edgewall and use that as a collision mesh, it was more efficient to use Havok cubes. Now moving and scaling a bunch of cubes would be relatively slow and tedious, but what made the task worse was the fact that the Havok nodes don't even respect 'normal' scaling and transformations, instead require custom parameters in the Havok node to be updated. An acceptable method for a prop or character model, but not a huge stadium.
The solution I came up with was to generate these collision cubes (or polygon meshes to aid visualization) from a 1-degree curve the user could quickly create and snap to the vertexes of the source edgewall mesh. The curve could be edited and the the collision meshes would be deleted and regenerated when the script was run again.
As curves were invisible to the environment mesh pipeline, they could be kept in the source stadium scene without any issues. Being collision of course, it would be unlikely to be perfect first time. But having to remember the parameters for each spline would be impossible, I gave the user the option to bake and store the current parameters (as custom attributes) into each individual curve. These can be used in preference to, or they can be extracted and replace the current UI settings (to for instance rebuild collision with a different curve with the same values).
I used this script to generate accurate but efficient edgewall collision for all the 30+ MADDEN stadiums in a little under 2 hours, but the technology for the game to use it was never pursued beyond several meetings.
 |
|---|
Generate Havok collision cubes from template spline (MEL)
A script I initially wrote for myself. I found I was constantly having to do minor tweaks to lots of 3d files during the production of GEN4 MADDEN, due to some additional technical requirements or changes in how the pipeline and tools parsed the source data. I had a script that had been quickly written and hardcoded to batch through all the stadiums, which I would modify to do the new task.
Eventually I bit the bullet and decided to write a proper batch script to parse through multiple files via a source text file and to run the commands in a window on each file on that list. As MEL has the ability to parse a text file as MEL or as Python, I created the option to run both kinds of scripts. In addition I gave the option to save the changes made to each file or not, so that I could use the tool to parse each file and gather statistics on rather than modify the source files.
 |
|---|
Batch MEL or PYTHON script to each MAYA file listed in a .txt file list (MEL)
Import color point cloud data into Houdini (HOUDINI/PYTHON)
 |
|---|
While Tiger Woods Golf had been scanning golf courses to get very accurate terrain meshes for years, scanning sports stadiums was a relatively new idea with its own unique set of problems. We didn't have a good way of getting scan data into Houdini to skin it as a guide to generating an accurate and efficient 3d mesh. In addition, we had just purchased a scanner that captured color points.
While between projects, I was tasked with creating a custom Houdini node to convert scan data in several file formats (as well as an ideal task to get me up to speed with Python scripting).
I figured out the file format of the required point cloud data file, as well as that of the most common ones and wrote my Python script to handle multiple types. While fast, the input required the creation of millions of points and so would take a minute or two to run. Fine if everything is correct, but not very good when you are trying to figure things out. With this in mind I added parameters to allow for a quicker file input by only importing every nth point,as well as bounding box culls.
Still in use on several projects, but ironically never used on the projects I was assigned to.
Nvidia Iray for MAYA tools (MEL)
 Prototype UI to help user generate complex LPE's without knowing the LPE syntax |  Helper script for vMaterial MDL material library to help user visualize each of the shaders |
|---|---|
 ID status 'at a glance' display/modifier script. ID's would change color when used, and with a brighter color for transform nodes compared to shape nodes. |
As workflow specialist at Nvidia for their Iray for MAYA plugin, it was my job to help users come to grips with this new physically based renderer.Part of the job was to identify problem areas, and prototype/design rendering workflows to either add as a custom MAYA shelf tool or to demonstrate the need to update the core plugin (or Iray SDK) feature set.
I wrote many scripts (sometimes to be used with custom MDL shaders I had also writen) to help convert to Iray materials and lights, set up render passes, tag objects with Iray attributes and manage object ID's. Quite a few were either dead ends or were superseded by improvements to the SDK and plugin.
Light Path Expressions (LPE's) were one of the most powerful features of this new renderer, but also one of the most underutilized or understood. While the regex syntax of the expressions was very simple to pick up, it represented a barrier to those users more used to presets than writing equations. So I created a prototype tool to help a user select some options using plain English and generate a valid LPE expression to do what they wanted without any technical knowledge at all.
vMaterials, a free professionally created MDL material library was offered for free to all Iray users. With over 1000 materials to pick from, it was difficult to find and track down a specific look from the Iray For MAYA Ui which listed all the materials as text names only. I created and shared a simple script to scour the users vMaterial library to find all the shader thumbnails and organize them in a simple UI, while we looked for a more permanent solution. Each material was presented as a thumbnail button. Hovering over the button would give additional information whereas clicking the button would either create the material (if it didn't already exist in the scene), create and assign the material (if the material didn't exist and some objects were selected) or simply assign (if the material already existed and some objects were selected).
Object ID's were a useful way of tagging certain objects/groups of objects. However as bith shapenodes and transform nodes could be tagged, it wasn't easy to check the scene at a glance to see what was tagged and what value it had. So I wrote a dual purpose color status display/ID modifier script.