3D pipelines and some… guidelines – UPDATED!
I’m in Montreal talking to ex-coworkers and their continuing struggles getting art looking “right” into their respective games. It’s amazing to hear how these gigantic studios are still struggling to get the fundamentals rights.
Anyhow, the process of putting 3D art assets into a game is called the “art pipeline” or “toolchain” or “asset conditioning” or how I call it generically “3D pipeline.”
The 3D pipeline has two major bottlenecks: software and people. Let’s ignore software one until a later post and focus on people. Oh the people…
Far too many producers and art directors think 2D assets can be managed like 3D assets: just create them and throw them into the game. Luckily this causes them to get fired or bankrupt the company.
The problem is that 3D assets like models, textures, and animations require more consistency and art direction that 2D assets like images. With 2D images, all that an art director needs to worry about is compression artifacts, film grain, gamma / colour uniformity. With 3D assets, there are scale, lighting, texture/UV mapping resolution, FPS, etc. issues.
Guideline for modelers:
- Use approved concept designs only.
- Ideally check for “3D” consistency issues between the concept designs that can make impossible to model. i.e Mickey Mouse’s ears can not be modeled typically in 3D – his ears always face the camera and are perfect circles. This requires a model + rendering hack.
- Use the same scale reference for all models.
- Know the polygon budget for the level/scene/world.
- Know the approx. polygon budget for your model.
- Understand how the model will be UV mapped if not by you.
- If you UV map, please keep it organize and try to use as much of the UV space as possible.
- For certain 3D packages, please clean up the construction history and temporary junk so it is not passed onto animators and texture artists.
- Check all normals for a consistent direction. In technical terms, all polygons should have a consistent winding order
- Check all polygons for T-junctions, bow ties, non-planarity and other degenerate problems.
- Reduce the number of polygonal intersections.
- If also creating physics collision meshes, keep them “manifold” – closed, non-intersecting, planar, etc.
- Check with riggers + animators on what areas of the model need to be deformed so more polygonal detailed can be added there.
- Preview all work regularly in the game or in a model viewer.
Guideline for shading + texture artists:
- Use a standardized lighting rig for all work – this guarantees shaders + textures created by different artists will at least be uniform (lighting-wise) in the game. If this is NOT done then a clean-up artists will need to fix all shaders and textures before the game can be shipped. In the film business this is the “colour timing” process, but in 3D it is lengthy and expensive – and requires art to be redone.
- Calibrate all monitors (if possible).
- Know your texture resolution budgets.
- Unless approved, do not use lossy compressed textures (tools will compress later). i.e. JPEGs bad. TIFFs, TGAs, PNGs, BMPs good.
- Try to create “unlit” textures as previous lighting will conflict with the in-game lighting. i.e Using photographs as textures is a bad idea because if say grass is being lit from the left by the sun and in the game the sun is on the right… the shadows will look wrong. The human brain can tell if something is wrong, but not always identify exactly what. This advice is crucial if bump or normal mapping, but not as important without.
- Ignore the advice if you are creating textures that requires “pre-lighting” or not using bump or normal mapping.
But…. Understand all photographs have pre-built in lighting that will conflict with CG lighting unless perfectly “matched.” - If you UV map also, please keep it organize and try to use as much of the UV space as possible.
- Keep the number of shaders to a minimum – the game will perform better. Modern GPUs / games prefer fewer shaders due to the “batching rule.”
- Worry about texture stretching and texture resolution to object space consistency across different object. This is an advanced topic, but you can notice this problem in 3D games easily by comparing the floor/ground to the character. The ground is typically poorly mapped and textures are stretched/blurred but the character has clean + sharp textures.
- Preview all work regularly in the game or in a model viewer.
Guidelines for riggers:
- Know the maximum number of bones that can be assigned to each vertex.
- Check the number of bones assigned to the vertices (usually in the 3D package or examining the mesh XML file).
- No IK
- No constraints
- No complex deformers (lattices, wire deformers, 3rd party plugins, etc.)
- Name the bones! Something human readable.
- Normalize weights!
- Keep the rig simple, but too simple.
- Create nulls/locators/control curves for the animators, but make sure the exporter doesn’t export these.
- Add geometry when necessary, but avoid changing UVs / texturing when doing so.
Guidelines for animators:
- Know the frame-rate in which you’ll be animating to.
- Understand the animation curve limitations of the game engine – linear curves, splines, in and out tangents – so you what you are animating will look as it does in your 3D animation package.
- If cycling an animation, check for that the first and last frames match. Better yet, copy the first frame onto the last frame.
- Keep track of the stride length (the distance a character walks in one cycle) – this will prevent feet from sliding.
- Feet will almost always slide in 3D games, but it’s best the animation cycles don’t have that in the first place!
- If you use constraints or IK or an advanced animation tool you may be forced to bake out the animation into keyframes.
- Don’t bake out all your keyframes unless told by a TD/programmer.
- If you are also the rigger, consistently name the bones and keep the number of bones to a minimum. A named bone can be exported and used in a game easier than joint34124.
- Preview all work regularly in the game or in an animation viewer.
Will continue with the software side next week and polish this posting up at a later date.
Add comment July 20th, 2007