Chapter 1: Modular Kits & Hardpoint Standards

Created by Sarah Choi (prompt writer using ChatGPT)

Modular Kits & Hardpoint Standards

Optimization, Modularity & Families

Modularity is how you scale a vehicle roster without scaling chaos. A kit‑of‑parts, anchored by hardpoint standards, lets concept explore boldly while production ships fast, consistent, and performant assets. This article outlines how to design modular kits, choose and document hardpoint standards, and think in trims, variants, and LOD from the outset—equally for concept‑side and production‑side vehicle artists.

1) What “modular” really means in a vehicle pipeline

Modularity is not just reusing a door. It is a language of interfaces—mechanical, electrical, thermal, and data—tied to geometry, rigging, and materials. A kit becomes scalable when parts share datums, bolt patterns, connector zones, and naming, so they can swap without re‑authoring collisions, VFX sockets, or audio hooks. Done right, kits multiply options (trims, roles, factions) while reducing unique asset count, texture memory, and animation cost.

2) Start with family architecture: spine, bays, and skins

Define a family spine (chassis rail set, fuselage keel, hull stringers) that stays invariant across the line. Around the spine, reserve bays—standard rectangles or arcs—for power, cooling, payload, crew, and gear. Wrap with skins (outer panels and fairings) that can stretch within defined ranges without breaking interfaces. From the first proportion pass, sketch these as ghosted frames so later kit parts have homes. The result is a platform that spawns trims (base/cargo/recon/assault), not one‑offs.

3) Hardpoint standards: decide and publish the rules

A hardpoint is a promise. Publish a short spec for each interface:

  • Mechanical: bolt circle diameters (e.g., 4×M12 on 100 mm BCD), slot ranges, shear key orientation, allowable overhang, max mass.
  • Electrical: connector envelope, pin count, voltage/current, strain‑relief path, EMI shielding clearance.
  • Thermal/fluids: duct cross‑section minimums, radiator face zones, hose diameters, keep‑outs for heat plumes.
  • Data/rig: required joints (hinge.cargo, gimbal.ISR), axes, default limits, and socket names for VFX/audio.
  • Collision: proxy shape envelope and clearance gaps that must be preserved. Publish these on a single “HP Standard” plate with scale bars, axis convention, and a callout legend. If a part fits the spec, it should fit any vehicle in the family.

4) Kit design: primitives first, detail later

Author every module in two grades:

  • Primitive‑grade for ideation and speed‑cage: clean planes, minimal bevels, correct pivots, named sockets, 500–3k tris.
  • Production‑grade for finals: clean topology and UVs, material IDs, LODs, collisions, and the same pivots/sockets. Keep the footprint identical across grades so you can swap without moving anything downstream. Provide preview cards with unit scale, pivots, joint list, and compatible hardpoints.

5) Trims and variants: a constraint game, not a repaint

Trims differ by capability reads and a few modules, not by random new parts. A Cargo trim might swap roof panels for rack modules and extend ramp length; a Recon trim swaps side armor for sensor masts and low‑profile cooling; an Assault trim widens track and mounts a turret on the same BCD. Each trim should reuse 60–80% of parts by count, 70–90% by texture memory, and 100% of hardpoint definitions. Show a family grid early with which modules change per trim to keep scope honest.

6) LOD thinking from day zero

Plan LODs per module, not only per vehicle. LOD0 carries hero forms and decals; LOD1 reduces triangles by ~35% and merges small chamfers; LOD2 reduces ~60% and collapses micro‑greebles into baked normals; LOD3 replaces with simple hulls. Keep pivots, sockets, and hardpoint footprints identical across LODs so rigs and effects never pop. Share trim sheets and decal atlases across the kit so memory scales with family size, not the SKU count.

7) UVs, decals, and livery zones for reuse

Use trim sheets for fasteners, vents, and grills. Reserve flat decal pads on skins near hardpoints for numbers, insignia, and hazard frames; keep them unwarped and large enough for 1s/3s/5s readability. Provide a livery zone map per skin and declare no‑wrap areas where typography would distort. For modules, standardize decal anchor UVs so a single number block can appear in the same relative spot across trims.

8) Rig & socket portability

A reusable module is only reusable if it behaves the same. Lock joint names, axes, and limits for kit parts (ramp.hinge, gear.FL.upDown, turret.yaw/pitch, gimbal.pitch/yaw). Place VFX and Audio sockets with stable names (vfx.exhaust, vfx.intake, vfx.dustDownwash, audio.hinge.lock). Export a tiny rig spec with each module (CSV/JSON) so animation/vfx can auto‑bind. When a module ships, its behavior should plug into any parent with no script edits.

9) Collision & metrics as first‑class citizens

Every module needs a matching collision proxy with the same name prefix (e.g., col.ramp, col.turret, col.skirt). Validate approach/departure and breakover on the assembled trims with physics hulls before polishing surfaces. If a module steals critical angle or clearance, fix the interface or change the module; do not fudge metrics per trim. Keep soft volumes for proximity triggers and hazards parented to modules so Gameplay logic scales with the kit.

10) Thermal, service, and damage logic

Standardize service access: fastener families, panel swing arcs, and tool clearances. Design sacrificial skins that fail cleanly away from structure and expose consistent attachment points for damage kits (bent beams, torn skins, frayed cables). Modules should ship with damaged LODs that reuse the same pivots and sockets so damage states can be automated across trims without bespoke work. Thermal modules (radiators, exhausts) must keep their keep‑outs regardless of skin.

11) Governance: how the library stays healthy

Treat the kit like code:

  • Versioning: semantic versions for meshes/materials (v2.1.0), CHANGELOG, and thumbnails per release.
  • Ownership: a maintainer per module; PRs reviewed like code.
  • Validation: pre‑flight scripts check units, pivots, LOD presence, UV ranges, socket names, and collision coverage.
  • Deprecation: mark legacy parts, provide migrations, and forbid zombie copies in project trees.
  • Metrics locks: red lines (angles, clearances) that cannot change without a system‑level decision.

12) Optimization levers that come “for free” with kits

  • Texture memory drops when trims share atlases and decals.
  • Draw calls reduce as modules reuse material IDs and atlases.
  • Rig time shrinks when joints and sockets are identical.
  • QA accelerates because behaviors repeat; test once, trust across.
  • Photobash & paint speed up with recurring flats and anchor pads.
  • Outsourcing becomes safer: vendors receive ironclad standards and validation scripts.

13) Concept workflow: ideate in kits, not one‑offs

During Ideation, block vehicles with primitive‑grade modules and skins to test stance, light, and metrics. Annotate sheets with the hardpoints you intend to use; if a hero shape fights standards, document why. In Iteration, try 30% deltas by swapping modules, not redrawing entire vehicles: long‑bed vs short‑bed, narrow vs wide track, low‑profile cooling vs tall stacks. In Finals, freeze the spine and hardpoints, then choose a trim to prove. Handoff includes the module manifest and hardpoint table so production can assemble without guessing.

14) Production workflow: assemble, validate, then optimize

Start by assembling the trim from approved modules. Run physics sweeps and articulation tests, then only surface polish. Bake normals once per module and share results across vehicles. Generate LODs per module, verify socket and pivot continuity, and stamp a module audit thumbnail (wire + clay). Export FBX/GLTF with hierarchy, collisions, and rig data intact. Any deviation from standards should be flagged in the manifest with a mitigation or a plan to update the standard.

15) Case study: light utility rover family

Spine: 2.9 m wheelbase ladder frame with four suspension hardpoints and two roof rails. Bays: front power, mid cabin, rear payload. Modules: two front bumpers (civil/mil), three payload decks (flat, rack, box), two cooling packs (low profile / high‑capacity), one ramp set, one ISR mast, one RWS turret, two roof skins. Standards: front bumper BCD 4×M12 100 mm; roof rail clamp 60 mm pitch; electrical bus 48 V with standardized connector bay; duct CSA ≥ 180 cm². Trims: Cargo (flat deck + low cool), Recon (box + ISR mast), Assault (rack + high cool + RWS). Reuse: 78% part count shared across trims; 85% shared texture memory; zero rig edits between trims. Performance: LOD0/1/2 per module; decals shared; collisions identical. Team ships three vehicles in the time one bespoke build would take.

16) Common failure modes & fixes

  • Pretty vs standard: a hero panel ignores BCD or bay size → redesign the panel or elevate the standard; do not create one‑off holes.
  • Pivot drift: modules mirror with negative scales → instance‑mirror or re‑export with positive transforms.
  • Socket entropy: names change per artist → enforce a naming linter and export validator.
  • Metric rot: trims quietly erode approach/departure → add a metrics overlay to assembly scenes; block merges if violated.
  • Texture sprawl: every module gets a unique 4K → move to shared atlases and trim sheets; reserve uniques for hero skins only.

17) Handoff manifest (one page)

  • Vehicle ID & Trim
  • Spine version
  • Module list (name, version, filepath)
  • Hardpoint table (ID, position/orientation, spec version)
  • Rig table (joints, limits, parents)
  • Sockets (VFX/audio names and parents)
  • Colliders (names, types)
  • Materials/Atlases (IDs, texel targets)
  • LOD summary (tris per level)
  • Metrics (L/W/H, wheelbase/track, angles/clearances)
  • Known unknowns / risks

18) Closing thoughts

Modular kits and hardpoint standards turn creativity into a platform. Concept can compose vehicles like sentences from a shared alphabet; production can ship families with controlled budgets and predictable behavior. When interfaces are explicit, trims and variants become a design choice instead of an engineering burden, and LOD, rigging, VFX, and audio all plug into the same backbone. The result is a roster that feels rich on screen and sane in the build system.