A 3D game asset workflow – Part I

The theory – Overview

Introduction

In this article I’d like to show you a workflow which I often use when creating setpiece game assets. The idea is not earthshaking and I’m sure many artists are doing something like this already. However since I failed to clearly explain this to people on more than one occasion, I decided that writing an article might be good for future reference.

In this part we overview the theory which can be adapted to any 3D package which has object baking and rapid preview functionality.

The second part of the article is a more in-depth explanation of the steps, along with some tips and tricks.

The last part is a case study using Luxology’s 3D package, modo.
With version 401, modo has finally matured enough so all 3D work can be done without switching applications. Unfortunately modo still has serious problems regarding the shader tree and texture baking, so the procedures are much more involved as they should be. Yet, I hope showing the idea, the problems and the workarounds will be helpful at some point.

Here I’d like to thank Tamas Szabo, a talented 3D artist, for his strenuous skepticism and fair criticism.

The classic workflow

In previous generation games, the artist modeled the object, made the UVs and created a texture for it in Photoshop.
This old-school method was developed in the late 90’s, early 2000’s, in an era when there was seldom need for more than a diffuse map and the 3D hardware and software technology was much less advanced than today.

We took pictures with our new, bleeding edge, 2 megapixel digital camera, turned them into textures using Photoshop 5.5. Then we aligned those textures on BSP brushes or mapped them onto objects of 700 something polygons. The surface properties of an ingame mesh were very simple, so a simple textured OpenGL view was enough to check how the final object will look like.
Offline (raytrace) rendering was pretty much useless for a game artist: it was slow and the result was very far beyond the visuals of a game.
The now oldschool workflow was efficient back then as it made the best of the tools available at the time.

A decade has passed and with current-gen engines the challenges have changed.
Modeling is now often involves two objects: a high poly model for maximum detail and a low poly one for optimal performance.
So your common, or garden variety artists model both the high def and low def objects in a 3D software and bake a normalmap to the low poly mesh (which stores the geometry details of the high poly object in the texture).

Then they open up Photoshop and start creating the diffuse, specular, transparency, emissive, etc maps, using the baked normal and ambient occlusion maps as a guide to get some idea about the underlying mesh. They are still using a 2D application to work on the 3D object, just like a decade ago.

Here are the most significant problems with that practice:

- The ingame object’s UV set must be artist friendly, which is usually sub-optimal from a technical point of view.
The engine doesn’t care if the pieces are all over the place, tightly packed, but a texture artist can only work fast with an easy to understand arrangement.

- Difficult to follow changes.
If the UV changes later on then the artist have to start over the texture creation, or at least part of it.
To avoid the extra work, the UV might get frozen. In that case if the geometry needs to be simplified then removed polygons might leave holes in the UV, wasting texture space.
If a reasonable number of extra polys are added then chances are that due to the suboptimal UV arrangement (see above) there are unused areas where they can be mapped. If that’s still not enough then it’s “Draw it again, Sam”.

- Task ping-pong between specialized artists.
Often different artists create different aspects of an asset. Modelers model and create the UVs, texture artists make the textures based on those UVs, and they also have to do the “export-import-check textures in 3D” cycles.
If the UV has a problem, then the texture artist throws it back to the modeler, who might be working on another task already. They fix it some time later, at which point the texture artist might have started working on another task… and so on.
If the “check textures in 3D” step is done in the game engine, then technical considerations come to play: LOD groups, compression methods, shader selection, etc. Texture artists seldom learn the tricks of that area of expertise (it’s not their real job after all) so yet another artist has to get involved and (re)do the tech stuff sooner or later.
These inter-artist dependencies mess up schedules and there is no way to really finalize and close sub-tasks, only the final object.

What all this boils down to is that this legacy workflow slows down the asset creation process, especially when something needs to be changed or fixed.

Artists are hard working people, who are well worth a cleaner, more intuitive workflow.

Something like this:

An updated workflow

	High poly object modeling No limits, make the geometry any way you want.
	High poly object texturing No limits, use any technique you want. You’ll need very fast preview functionality for quick feedback (like modo’s preview viewport or FPrime).
	Freezing design, releasing asset The reference visuals are now done. If the lead artist accepts it then this sub-task is done. It is not affected by the following sub-tasks, the involved artist can move on.
— Passing task to another artist —
	Low poly object modeling Same challenges as before, nothing new.
	Making UVs Aim at maximum efficiency. Automated UV packer tools give a great base, but before releasing the asset, a final, manual pass is highly recommended.
	Baking everything Set up the baking and transfer the look of the high poly object to the low poly one.
	Freezing technical aspects, releasing asset If the technology officer accepts the asset (polycount, textures, collision, etc are all cool) then this sub-task is done.
— Passing task to another artist —
	Transferring the asset to the engine Asset import, setting up collisions, texture compression, mipmap settings, lightmap resolutions, physical properties and the like.
	Tweaking the shaders in game After setting up the technical aspects of the shaders used, the goal is to make it look good. Although the offline and realtime rendering methods are totally different under the hood, the ingame visuals can be brought pretty close to the original.
	Freezing the final look, closing task. When the asset looks and works as designed, then the whole task can be closed.

If a single artist works on the asset from start to end, the workflow can be optimized:

- High poly object modeling.
- Low poly object modeling.
- Making UVs.
- Baking normals.
- Low poly object hi-def texturing: No limits, use any technique you want.
- Freezing design.

- Baking everything: Collapsing all the hi-def surface information into single textures.
- Freezing technical aspects.
- Transferring the asset to the engine.
- Tweaking the shaders in game.
- Freezing the final look, closing task.

The high poly texturing can be skipped in favor of high definition texturing on the low poly object, because one person can quickly move back and forth between steps.
In this case the “object-to-object” baking is needed only for generating normalmaps. The rest of the surface properties can use a simple “collapse layers” kind of bake, which is like merging layers in Photoshop.

So, these are the outlines of my proposed workflow. The next part will explain those steps in more detail.