     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Effective 3D Exporter Design: There's a common feeling in the game industry that many programmers don't 'get' artists, and visa versa. This often results in artists making fun of programmers for speaking geek, and programmers making tools that force artists to do more work than they should have to.
This article is about how you can make your 3D graphics exporter tools better, in terms of helping your artists get their job done. If you're lucky, this will get your project better art, which will mean bigger sales, and more money, fame and fortune. Plus, maybe your artists will actually like you for helping them do their best work! Philosophy It may sound namby-pamby, but I think it's a good idea to come up with philosophical guidelines when you are designing your tools, to give you something to judge your choices by. Here are some of mine. - Make your tools "bullet-proof" Obviously, the artists don't try to break your 3D exporter, but if you make them juggle eggs, then the yolk will be on you occasionally. If your tools are designed such that it's easy to make mistakes, people will make mistakes. If it's possible to design them so mistakes are harder or impossible, then you'll save a lot of time in the long run. How many times have you spent hours tracking down a crash bug, only to find was bad data, data you could have prevented from being bad in the first place if your tools checked for it? To give you a concrete example, I once received a skinning library and exporter from another team. I immediately made a simple test and tried to run it, and it crashed with no explanation. After asking one of the artists familiar with the exporter, he messed with it for about 2 hours and finally gave up, not able to get it to work. So, it then got passed on to one of the programmers more familiar with the code. After an hour or so of passing the files over to him, he told me 'Oh! You need to have 4 or less influences per vertex.' That's fair enough, but why does the tool crash? First, the library could check for too many influences - at least the debug version. Second, the exporter could do a similar job. The exporter might be more useful if it's flexible enough to handle more than 4 influences - maybe it should be designed to take some kind of project-based configuration file, so that you can specify the limits for a particular system, and it can check for them and warn you. I'm sure that the same scenario that I went through happened several times during the project: artist adds new art, game suddenly crashes, hours are spent tracking it down to the problem of too many vertex influences. In fact, some commercial engines that I've seen can export data that crashes the engine. What were they thinking? The exporter should never export data the engine can't handle. As well as this, the engine or tool, at least in debug mode, should check that the data is correct. Otherwise, you're just asking for hours of debugging. So, again, make your tools bullet proof! - Don't force your artists to speak to a programmer in order to work out why something doesn't work. If your artists have to come to you every time something doesn't work, then you're going to be chasing down issues for your artists all the time. Anything you can do to design your tools so that artists can figure out the issues on their own means you can work on other things, and everyone can get their work done faster and with less frustration. - Make the tool, not the artist, do the non-artistic work. This is pretty simple. Basically, don't force the artists to do things a trained monkey could do. An extremely simple example would be - don't force them to break up their quads into triangles. If you are passed a quad and you need triangles, then silently make triangles. Of course, you should probably check if it's planar or not and mark it as an error or warning (see below). But the point is - wherever possible, do the obvious thing. - Make it possible for your tools to work as part of a one-step build process. You've probably heard about a one-step build being a good idea. The one-step build avoids human error, by eliminating all manual steps in the conversion of human-made creative assets to game-ready data. In particular, this means that artists should not be required to manually re-export their 3D models. They just create the models, textures, level maps, and so on. The build tools will export them as necessary (when they are newer than the game-ready versions of the same data.) An added benefit of the one-step build is that your artists spend most of their time creating art, instead of repeating non-creative tasks that automated systems could do a lot faster and cheaper. - Make your tools to support the way that artists work. There's
a point to this piece of philosophy. Never forget that the goal
of your tools is to help the artists make great art. You do that
by designing your tools to support all the features and techniques
that artists typically use. We'll go on to discuss some examples
of how this philosophy comes into play.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Introduction
Features
|
|
|