Skip to content

art-blockout-spec.md

Latest commit

 

History

History
195 lines (136 loc) · 5.61 KB

art-blockout-spec.md

File metadata and controls

195 lines (136 loc) · 5.61 KB

Art Blockout Spec

Status: graybox art contract for the current vertical slice. This is not a final art bible. The goal is to replace generic cubes with readable low-cost machine silhouettes while keeping strong fit with the current simulation and slicing tools.

1. Scope

Author blockout assets only for the current playable set:

  • frame_block
  • wire
  • belt
  • lift_wheel
  • dynamo
  • extractor
  • crusher
  • mixer
  • press
  • fabricator

Do not spend time on:

  • final textures
  • hero props
  • high-frequency detail
  • rigging
  • particles
  • decorative environment dressing

2. Grid Contract

  • 1 grid cell = 1m
  • World axes:
    • +X = east
    • -Z = north
    • +Y = up
  • Canonical authored orientation is north-facing
  • Runtime rotates assets in 90-degree horizontal steps
  • Most slice machines occupy 1 x 1 x 1
  • lift_wheel currently occupies 1 x 2 x 1

3. Pivot And Bounds

  • Put the object origin at the bottom center of the machine origin cell
  • Rest the asset on Y = 0
  • Do not leave a visible hover gap under the base
  • Keep the visible body inside the occupied footprint whenever possible
  • Small overhang is acceptable if it does not obscure neighboring cells during slicing
  • Avoid thin shapes that disappear from an angled top-down camera

Recommended visible bounds:

  • Single-cell machine body: roughly 0.78m to 0.94m wide/deep
  • Single-cell machine height: roughly 0.7m to 1.05m
  • Infrastructure pieces can be lower profile if they remain readable

4. Material Rules

  • Prefer 1 material, maximum 2 materials per asset
  • No baked lighting
  • No emissive-heavy treatment in the first pass
  • Keep surfaces broad and simple enough for flat or lightly varied materials
  • Author for category color tinting, not bespoke texture storytelling

5. Readability Priorities

Readability matters more than realism.

Every asset should make these things obvious:

  • where the machine faces
  • where item output is likely to leave
  • where power connects if the machine uses power
  • where the machine contacts the floor/support
  • whether the object is infrastructure, processing, power, or utility

Preferred visual language:

  • processing machines: enclosed bodies, hoppers, chutes, vats, or presses
  • transport: lighter, more linear silhouettes
  • power: heavier, generator-like forms with coils, flywheels, or terminals
  • utility: workshop or assembly silhouettes
  • structure: neutral support geometry

6. Port Readability

The game already draws overlay markers, so the model does not need literal sockets everywhere. It should still support the port grammar.

Use shape cues for:

  • item input: hopper, tray, chute mouth, intake frame
  • item output: spout, chute, nozzle, ejector side
  • power input: terminal, insulated coupling, connector plate
  • power output: generator face or terminal ring

Do not encode gameplay with tiny decals alone. The silhouette should do most of the work.

7. Per-Machine Notes

frame_block

  • Neutral support piece
  • Must tile cleanly
  • Should read as structural, not decorative masonry

wire

  • Low-profile connector
  • No strong front/back
  • Can be authored as a grounded cable tray, insulated bar, or conduit node

belt

  • Must read as directed transport
  • Output/front should be much clearer than intake sides
  • Intake from back or side is allowed by gameplay, so do not make the side faces look forbidden

lift_wheel

  • One cell wide, two cells tall
  • Clear vertical motion silhouette
  • Bottom intake and top output should be readable

dynamo

  • Distinct from all processors
  • Power identity first
  • All four horizontal sides are power output faces in gameplay

extractor

  • Should look anchored to a node
  • Front item output and rear power input need clear separation

crusher

  • Feed in, process, eject out
  • One power side
  • Heavier, more blunt silhouette than the mixer

mixer

  • Two different side inputs matter
  • Should visually support the idea of combining two feeds into one chamber
  • Output and power side should not be ambiguous

press

  • Strong front-to-back material path
  • Should feel like compression or stamping, not generic processing

fabricator

  • Utility machine, not part of the core chemistry chain
  • Should feel like a workshop/fabrication station that consumes plates and credits build inventory

8. Export Rules

  • Export as glb
  • One file per machine
  • Recommended filename: <machine_id>.glb
  • Keep transforms applied before export
  • Keep the authored pivot/origin intact
  • Do not include cameras or lights

Recommended target path once runtime asset mapping is added:

  • assets/models/<machine_id>.glb

Current content wiring:

  • machine defs can now point at blockouts with render.model: "models/<machine_id>.glb"
  • runtime rotates the imported scene from the authored north-facing orientation
  • render.model_scale and render.model_offset exist for minor correction, but Blender pivots should stay the primary fix
  • if a model is missing, not loaded yet, or hidden by readability rules, the client falls back to the built-in cube body automatically

9. Asset Acceptance Checklist

An asset is good enough for this stage if:

  • it fits the declared footprint
  • it reads from the game camera without zooming in
  • it makes facing clearer than the current cube
  • it survives slice viewing without becoming visual noise
  • it does not rely on final textures to communicate function
  • it can be tinted or paired with simple materials cleanly

10. Current Recommendation

Start with these three first:

  1. belt
  2. mixer
  3. dynamo

Those will do the most to improve readability fastest. After that, finish the rest of the current slice kit before adding any environment art.