The first step toward improving speed involved the unwrapping of mapping coordinates for light map rendering. This needed to be as automated a process as possible. Expecting artists to generate by hand a second set of efficient mapping coordinates for every piece of static geometry in the world is asking for trouble - both for scheduling reasons and for my personal well-being!
In old-school level design tools (and many recent ones), all the environmental geometry is made of primitive convex objects such as boxes and cylinders and spheres. The tools merge them, cutting away the unused and unseen portions, and at the same time generate mapping coordinates.
Because the starting geometry is simple, the results are somewhat predictable. Our modeling needed to be done entirely in 3ds Max and the triangular mesh results were anything but!
We needed an unwrap procedure that would generate efficient results and be simple to use. Full automation was a bit much to ask, considering the complexity of the geometry we were working with, but I wanted to get as close as possible. The result of that effort was a mapping tool with a few handy functions and an automatic unwrap function.
Another issue that needed to be addressed was the efficiency of drawing complex interior spaces in the game. Although the triangle counts of hand built geometry was going to be considerably more manageable than what would be produced by a level design tool, it was certainly not negligible.
The proposed solution was to use a manually set up portal system. Interior spaces would be broken up into rooms that could be connected together via their doorways. Simple geometric objects would be constructed to represent every door and window and others to represent the space that could be seen through them, to which the actual visible geometry would be linked. All of this was to be set up by the responsible artist and named according to a strict convention.
Interior spaces would therefore be intricate networks of geometry that had to be prepared with extreme precision. Since naming the objects correctly seemed to have tremendous potential for error, my plan was to write a script that would auto-rename everything that had been assembled based on placement and a few math functions. Eventually, that script turned into a methodology for how the interior geometry was to be constructed and set up using pre-fabricated building blocks.
The decision to build interior spaces out of pre-fabricated parts had implications for our tool set. It became clear that keeping track of the numerous models populating the world was going to be a headache. Also, we needed some form of source control. Multiple artists were working on various parts of the same space and we needed a way for them to do so without stepping on each others' toes.
We were using SourceSafe, but although many coders swear by it, I found it to be somewhat unreliable for data tracking and from a script writer's perspective it was difficult to automate the checking in and out procedures. This prompted me to think in terms of making a more ambitious scripted application that would guide the whole process and keep track of assets rather than a series of individual unconnected scripts.
I wanted a tool that would organize and track assets (models and textures), generate thumbnail images, help with the assembly of interior spaces, rename portal objects according to our convention, assist with unwrapping mapping coordinates and rendering light maps, and export all of the data to the internal format used in the game. The next step was to decide how the data would be stored and retrieved.