     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Effective 3D Exporter Design: Automatic batching for 3D Exporters Following the "Make the tool, not the artist, do the non-artistic work", once you've solved the items above, it should be a relatively simple matter to make automatic exporting part of your build process. For Maya, you can use Mayabatch. You can pass Mayabatch a script that your build process creates to load and export a file. For 3D Studio Max, you can do the same with Maxscript by having your build process create a script to load a file, export it and exit Max. Another added benefit of not requiring manual exporting is that your artists will never wonder which Maya/Max/Lightwave file they need to load up, in order to edit an asset. The file they need to load will be the file that's in the build. However, I'm not suggesting there should be no way to manually export. I'm merely suggesting that your tools should be able to build in one step. Your process should facilitate matters, so that if you need to rebuild something, there are no manual steps required. If you need the ogre model rebuilt, you should be able to say something like "rebuild ogre". The alternative is to hunt down the one artist in your company that worked on the ogre, knows which of 45 files named ogre_23.max, ogre26.max, ogre25b.max, ogre-test3.max, and so on need to be loaded, and then where and how to export it. This is not a very appealing process. For example, in a recent project, we used some 3rd party tools that didn't follow this advice. We had a character with eight animations. As I was programming, there were several times I had to ask my artist to add a few nodes to the character's hierarchy. Because the system didn't support a one-time build solution, each time he edited the character, he had to hand export the model, and hand export each of the eight animations. This included editing several exporter settings before each export. If the exporter had been designed better, he might need to only press one button to get all nine files exported, after having done it the first time. In this case, the multi-stage export is still not the end of the story. The artist had to then take each of the nine exported files and copy them to the correct places in the build. If the tool truly supported a one-step build, that entire ten minute manual labor error prone process would have been reduced to saving the file and saying "done!".
There are levels or stages of one-step building. Sometimes, you want an immediate export-like function to iteratively edit an object being used in the current level. Other times, you want to click one button or type one string, and have a particular object or level and all its updated assets re-exported and reprocessed. Other times, you want all of it re-exported and reprocessed from scratch. Or possibly, you might want to rebuild the entire game. Your tools should support all of the above. If your exporter just supports manual exporting, only the first option is available to you. If your exporter is based initially on automated exporting, all the other options are just simple interface issues. Separate Exporting from Specification Some people will read the above ideas and believe what I'm suggesting is a system that uses a specification file, as opposed to a WYSIWYG system, but please don't make that mistake. In other words, some imagine some ugly non artist-friendly text file that specifies what and how to export stuff, versus the common method of exporting that you currently see in the 3D package. Although the ideas above require a specification, that doesn't mean making the spec couldn't be WYSIWYG. For example you could make a plug-in for your favorite 3D software that looked at the current scene, what's visible and what's not, and generated a specification file for the exporter system. This would essentially give you the same functionality as a normal no-specification file system, but it would have all the advantages above plus more. For example, with a specification-centered file system, you can have multiple characters per 3D file, and extract each character separately. That would be useful for genres like fighting games, where there are animations and moves that combine two or more players and complex movies such as throws. The artists would find it hugely beneficial to be able to keep both characters in one file, and animate them together. Another advantage is that using a specification file reduces the chance for human error in the build. Sure, the artist might forget to add something to the spec file if they add a new object in the scene. But the chance for that mistake happens only once, when they add something new or delete something. With a good preview system that will be known almost instantly. In contrast, relying on a manual exporter system creates an opportunity for error every time a file is saved - i.e. every time an animation is tweaked, a texture remapped, a property edited, etc. So, not only is the spec file system more powerful ( allowing multiple animations, characters and other actions per file), but it drastically reduces the chances for errors. All the while, this doesn't restrict the artist from having other scaffolding in the file to help them do their job. Separating the exporter from the specification file generator also gives you unlimited options regarding how to generate the spec. You could:
If you make your specifications text or XML-based, you'll have the option to hand-create them when needed, on top of generating them like mentioned above. In fact, although it can be a cop out, if you make a good exporters that export based on a specification, you can start with hand written specifications. Then, as your team has time and finds new issues to solve, you can make more and better specification generation and editing tools. Those tools could be any of the spec-making plug-ins mentioned above, or they could be Microsoft Infopath-based XML or a web-based editor with a list of each animation, starting and ending frames, and joints to include or exclude. The sky's the limit. There's another advantage in solving all of the above issues - the ability to allow the artist to create 3D cut-scenes completely in their favorite 3D package. There's no more having to edit the camera in-game, or assemble all the parts (characters, backgrounds, camera motion, character animations) separately, They can just make the perfect cut-scene using all the features of the 3D package. Then using a spec, either automatically or hand generated, all the required parts can be automatically exported and run through your tool-chain to get into the game. You
can even merge specs as well. You could pass the tools multiple
specs, and they would load all the items referenced by the various
specs, export them, and process them into a single bundle of data
for loading. This is a great way to bundle together related data
that is best edited separately. Conclusion: happy artists make better games! I hope this article has pointed out why it's important to design your tools with a philosophy in mind. My impression is that most tools are designed by a programmer, for a programmer, to supply data for other programmers. Therefore, the work flow of the person who is going to use the tools is not carefully considered. Nor are possible ways to avoid errors. Game library code writers are often some of the worst offenders, not because they are not smart, but because their sole goal in writing an exporter is generally to make some test data for their library. No thought is given to using the tool outside of that one small case. I think most tools would benefit from taking these kinds of ideas and philosophies into consideration during their design. While some of these ideas might be more work than the simpler solution you are living with now, it only takes one programmer to implement a better solution. The solution will effect, help and benefit 10 to 150 artists, which will more than pay for itself over the course of the project. In the end, the more you help your artists, the better job they will be able to do. That's not only going to mean better art and more sales, but it will mean less stress for you and maybe even some compliments from your fellow artists. What, compliments to a programmer from an artist? I bet you thought it was impossible! Acknowledgements I
wanted to thank all the people that helped me with this article.
This includes personnel from Atari, Inxile, Humongous, Naughty Dog,
Electronic Arts, Capcom, Sony, and Activision.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|