Chapter 2: Kitbash Libraries & CAD Pitfalls
Created by Sarah Choi (prompt writer using ChatGPT)
Kitbash Libraries & CAD Pitfalls
Unit 25 — 2D / 3D Hybrid Methods for Vehicles
Kitbashing is a force multiplier for vehicle concept art, but it can either accelerate truth or bury a design in borrowed noise. CAD assets can be priceless references or hidden traps that poison topology, scale, and performance. This article lays out how to build and maintain a studio‑ready kitbash library and how to avoid common CAD pitfalls—equally useful to concept‑side artists who move fast and production‑side artists who must deliver clean, riggable models. The focus is practical: blockouts, kitbashing discipline, and photobash ethics.
1) Why kitbash—and when not to
Kitbashing buys time when you need believable affordances (hinges, latches, hubs, radiators, sensors, thrusters) without re‑inventing them. In blockouts, kit parts act as value‑shaping planes, setting stance, light breakup, and scale language. In production, standardized modules enforce consistency across a vehicle family. Do not kitbash when the part is the brand signature—hero headlights, canopy profile, or crown surfacing. If a kit part clashes with the silhouette sentence, discard it; design clarity beats speed.
2) Library design: taxonomy, versioning, and metadata
Organize by function, not by look. A simple top‑level taxonomy covers 90% of use cases:
- Structure (frames, ribs, spars, brackets)
- Motion (hinges, slides, telescopes, gear linkages)
- Propulsion (turbines, fans, nozzles, manifolds)
- Thermal (radiators, heat sinks, ducts)
- Electrical (bus bars, connectors, junction boxes, cable trays)
- Fluids (tanks, pumps, hoses, valves)
- Fasteners (bolts, pins, quick‑release, DZUS)
- Armor/Skirts (plates, skirts, ERA tiles)
- Sensors/Comms (gimbals, masts, antennæ)
- Human Factors (seats, steps, handles, restraints)
Each asset should ship with metadata: units, real‑world dimensions, pivot meaning, polycount/LOD, material IDs, license & source, last edit date, and owner. Store as a sidecar JSON or embedded in naming: KIT_Thermal_RadSlab_600x400x60_mm_pivot-centerLOD0_15k_srcA.pt.
Version like code. Use semantic tags: v1.4.2 (mesh adjustment), v2.0.0 (UV/material change). Keep a CHANGELOG so artists can audit why a part looks different after an update.
3) Authoring kit parts for speed‑cage and production
Build two flavors:
- Primitive‑grade: boxified, clean planes, minimal bevels; intended for speed‑cage and stance/light testing. These should render legibly in clay and AO, with 500–3k tris per module.
- Production‑grade: clean topology, UVs, material IDs, LODs, and collision proxies. Tris matched to platform budgets, with a read‑first philosophy—detail densest where gameplay/camera requires.
Keep pivots where reality expects—hinge axes on the hinge line, wheel hubs at bearing centers, gimbals at true rotational centers. Freeze transforms and record the intended up axis (+Z or +Y) and scale (1 unit = 1 cm or 1 m) in the file header and on the preview card.
4) Scale discipline and unit hygiene
Most kitbash breakage starts with units. Declare a studio standard and enforce it with import presets. Provide preview thumbnails with a 1 m cube or 6 ft human for scale. Include a scale bar in viewport previews. On ingest, auto‑check for parts outside sane bounds (e.g., a “bolt” that is 3 m long). Avoid negative scales; they invert normals and break rig mirroring.
5) Material IDs and read grouping
Even at blockout stage, assign stable material IDs: body, glass, rubber, metal_exposed, fabric, emissive. Production‑grade assets should ship with flat color swatches and a minimal material spreadsheet: name, role, typical roughness/metalness ranges. This lets concept paint‑overs inherit believable value grouping and lets tech art slot materials quickly.
6) UVs, texel density, and decals
Production kits must include UVs with documented texel targets (e.g., 512–1024 px/m for internal mechanicals, 1024–2048 px/m for hero exteriors). Prefer trim sheets and tiling for fasteners and grills. Provide decal anchor planes and “no‑wrap” warnings for curved surfaces to prevent warped typography later. Lock unique UV islands upright where possible to ease text placement.
7) Re‑topology for CAD→DCC: the usual traps
CAD exports (STEP/IGES/NURBS) are parametric and tessellate into polygons on export. The usual hazards:
- Inconsistent tessellation density: tight fillets tessellate into dense slivers; broad planes become sparse. Result: shading chatter and unusable LODs. Fix: retopo broad planes with even quads; bake CAD normals if needed.
- Non‑manifold/lamina faces: overlapping shells, zero‑thickness surfaces. Fix: run clean‑up tools, delete internal faces, solidify as necessary.
- Exploded ngons & micro‑triangles from curves and booleans. Fix: rebuild curves as simple arcs; re‑boolean in DCC with cleaner targets.
- Double walls/stacked surfaces: near‑coincident faces cause z‑fighting. Fix: choose one shell; offset interiors only if needed for thickness reads.
- Microscopic fillets & chamfers: below pixel size they cost triangles and wreck shading. Fix: delete; replace with shader bevel/normal bake.
- Inverted or scrambled normals: common on mirrored parts and mixed exporters. Fix: unify normals; harden intended edges.
- Unit drift: mm vs inches; 1 unit = 1 mm but scene expects 1 cm. Fix: standardize import presets and auto‑scale on ingest.
If you must keep CAD fidelity for baking, separate render‑only CAD from game geometry. Bake curvature/normal/AO from CAD to simplified meshes; never ship raw tessellated CAD to engine.
8) Topology standards for kit parts
Favor quads in curved areas, tolerate triangles in flats, avoid long thin slivers. Hold loops around apertures; clean, single‑ring bevels on hard breaks; G2 continuity only where the read demands it (shoulders, hero crowns). Keep poly density proportional to screen size. Provide LODs with consistent naming and tri reduction targets (e.g., LOD0→LOD1 −35%, LOD2 −60%).
9) Instancing, hierarchy, and naming
Name by function and side: hinge.cargo.L, hinge.cargo.R, gimbal.ISR.base, gimbal.ISR.pitch. Group logical sub‑assemblies and set parents to real kinematic relationships. Avoid deep, decorative hierarchies. Use instances for repeating fasteners and vents; instance break only when UV or unique wear is required. Document mirror behavior and avoid negative scales; use instance mirroring or duplicate + reset pivots.
10) Kitbashing discipline during blockouts
During speed‑cage and early blockouts, treat kits as proportion cues, not final detail. Boxify or decimate busy parts so they read as planes under light. If a part’s micro‑detail becomes visible at game camera, swap to its production‑grade sibling later. Always test from three lenses: low (player height), mid (orthographic/plan), and tele (beauty crop). If a kit part salvages a weak read but breaks the stance, change the stance, not the part.
11) Photobash ethics and source control
Photography is powerful for ground planes, sky plates, and material cues—but be explicit about authorship. Keep a sources.md per asset/plate with origin, license (CC0, CC BY, commercial stock, in‑house), and transformation notes. Do not lift distinctive trade dress or competitor concepts. Transform materially—perspective, lighting, silhouette integration—and never let a photo be the only evidence a form exists. Your blockout should stand on its own as a clay render. If you use community kit assets, respect licenses and avoid embedding anything you cannot clear later.
12) Performance budgets and viewport health
Kits rot when they crash viewports. Publish triangle budgets per class of part and per camera distance. Ship proxy colliders with names like col.chassis, col.turret, col.wheel.FL for early physics. Provide a thumbnail sheet with wireframe and clay; ban wireframes that look like sand—dense grids signal CAD dumps. Encourage artists to toggle x‑ray, normals, and overdraw to spot waste. Establish a hard rule: no bolt threads or knurling modeled unless they impact silhouette at LOD0 distance.
13) Export pitfalls (FBX/GLTF) and axis conventions
Agree on axis and scale: e.g., +X forward, +Y right, +Z up; 1 unit = 1 cm. Lock this into export presets and include it on preview cards. Common gotchas:
- Frozen transforms lost on export → rig pivots drift. Fix: freeze & bake before export; validate in a checker scene.
- Negative scales on mirrors → flipped normals and animation bugs. Fix: instance‑mirror, apply positive scales, reset transforms.
- Multiple material slots named inconsistently → engine creates duplicates. Fix: standardized naming & material libraries.
- Tangent space mismatches → normal map seams. Fix: use engine‑matched tangents; rebake if necessary.
- Smoothing groups hard everywhere or soft everywhere → lighting artifacts. Fix: mark intended hard edges; average the rest; check vertex normal length.
14) Turning real CAD into good kit parts
When you receive vendor CAD (e.g., landing gear, engine, turret):
- Audit: check units, dimensions, and assembly tree. Identify decisive geometry vs. cosmetic fillets.
- Cull: delete microscopic fillets, internal features, and fasteners below visibility threshold.
- Block: re‑build big surfaces as clean DCC meshes; keep a hidden CAD set for bakes.
- Pivotize: set meaningful pivots per sub‑assembly; record axes.
- LOD & UV: author game meshes with LODs and UVs; bake normals from CAD if helpful.
- Document: write a one‑paragraph usage note (scale, axis, rigs it fits, known gotchas).
15) Case study: hinge library that saved a production
A team shipped a hinge kit of 12 modules: straight, offset, piano, barrel, cam‑lift, and gas‑assist variants. Each had Primitive and Production grades, pivots on true axes, four material IDs, and LODs. Concept used primitive hinges in speed‑cages to block hatch arcs; production swapped to the matching production hinges at finals without moving pivots. Because units, pivots, and naming matched, rigging could auto‑bind constraints across the family. The kit paid for itself in a week by eliminating bespoke hinge rebuilds and preserving silhouette intent.
16) Common failure modes and their antidotes
- Library drift: different versions of the “same” part appear across vehicles. Antidote: central repository with read‑only release channel and pull‑request updates.
- Pretty trash: CAD dump looks “detailed” but kills shading and performance. Antidote: primitive‑grade sibling + retopo policy; CAD kept render‑only for bakes.
- Siloed ethics: untracked photos and unlicensed kits leak into finals. Antidote: sources.md requirement and periodic audits.
- Pivot lies: parts look right but pivot at wrong places; rigging hacks around. Antidote: pivot checklist and validation script on export.
- Over‑greeble: micro‑detail hides proportion problems. Antidote: grayscale and small lens tests; remove detail until stance carries.
17) Lightweight checklists
Blockout/Kidbash Ingest
- Units declared; scale checked against 1 m cube
- Pivots meaningful; transforms frozen
- Material IDs assigned (body/glass/rubber/metal/emissive)
- Primitive‑grade version exists for speed‑cage
- sources.md added for any photos or third‑party assets
CAD→Game Conversion
- Tessellation cleaned; non‑manifold fixed
- Micro‑fillets removed; double walls culled
- Normals unified; hard edges intentional
- Even topology on broad planes; LODs authored
- UVs + texel density within targets; decal planes provided
Export & Rig Prep
- Axis/scale per studio standard; no negative scales
- Pivots preserved in FBX/GLTF; hierarchy clean
- Material names standardized; collisions included
- Preview clay + wire thumbnails generated
18) Closing thoughts
A great kitbash library is a language, not a bag of parts. It teaches teams to make consistent decisions about scale, light, and affordances, while CAD awareness keeps that language readable and performant. When concept and production coordinate around clear units, pivots, materials, and ethics, blockouts stay fast, photobash stays honest, and finals arrive rig‑ready. Speed then becomes sustainable momentum, not accumulated debt.