monster/wardrobegod
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4 Commits 1 Branch 0 Tags 694 KiB
Python 71.8%
HTML 27.6%
Shell 0.6%
294af7cf1d
Go to file
type-two 294af7cf1d Phase 3: the 2D paper-doll tier — 392 garments you can actually change 
The flat cut-outs were the cheapest content on the board and the only tier with a shipping
consumer, but wardrobegod couldn't show one: scan() filtered PNGs out of garments/ (fixed in
Phase 0) and there was no compositor, no slots, no preview. Now there is a working dress-up.

· library/doll/ seeded with 90sDJsim's 441 shipped sprites (165 top, 110 bottom, 60 shoes,
  57 hat, base body) — an instant starter wardrobe rather than a cold start.
· tools/doll.py wraps djsim's compositor. It deliberately does NOT import doll_composite:
  that module pulls numpy at import time for a keyer and an HSV recolour we never use (the
  farm's RMBG-2.0 does our keying), and numpy isn't installable here under PEP 668. Instead
  the measured anchors are parsed out of its source with ast, so there is still exactly one
  source of truth and they cannot drift; place() is a pure-PIL port.
· slugify() reproduces djsim's item_art() _art_slug character for character, verified against
  it. That equality IS the drop-in contract — a near-miss silently falls back to generic slot
  art instead of erroring, so it's the kind of bug you'd ship without noticing.
· /api/doll/gen runs the proven pipeline: flux_local on SOLID GREEN -> farm RMBG-2.0 ->
  staged to 704x1408. Green is not a preference: grey and checkerboard backgrounds eat
  garments in the key, and flux can't spell, so no text ever goes in the prompt.
· /api/doll/compose composes server-side with PIL, so the browser preview and the exported
  PNG are the same bytes rather than two renderers that drift.
· /api/doll/export writes into a LIVE game directory, so it defaults to a dry run and refuses
  any stem without _i_ — overwriting a generic slot fallback would restyle every unarted item
  in a shipping game.
· UI: a doll 2D tab with per-slot pickers, randomise, strip, and export.

Verified: composed a dressed doll from real sprites (correct base->bottom->shoes->top->hat
order), catalogue reports 392 layers, export dry-run and the generic-art guard both behave.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 16:07:13 +10:00
tools Phase 3: the 2D paper-doll tier — 392 garments you can actually change 2026-07-24 16:07:13 +10:00
web Phase 3: the 2D paper-doll tier — 392 garments you can actually change 2026-07-24 16:07:13 +10:00
.gitignore Phase 3: the 2D paper-doll tier — 392 garments you can actually change 2026-07-24 16:07:13 +10:00
blender_ops.py WARDROBEGOD v1 — wardrobe generator bench (bodies, fits, garment gen pipeline) 2026-07-20 20:53:43 +10:00
README.md WARDROBEGOD v1 — wardrobe generator bench (bodies, fits, garment gen pipeline) 2026-07-20 20:53:43 +10:00
server.py Phase 3: the 2D paper-doll tier — 392 garments you can actually change 2026-07-24 16:07:13 +10:00
STATE_AND_PLAN.md Phase 0+1: unblock the bench, then make it dress and move 2026-07-24 15:43:02 +10:00

README.md

WARDROBEGOD — one skeleton, infinite fits

The wardrobe generator bench: load bodies (FBX/GLB/OBJ), build a clothes library, generate new garments on the farm, fit them, assemble dressed NPCs. Sibling of NPCFACTORY (the dress-up/clip bench) and MeshGod imagelab — this one owns clothing.

python3 server.py                 → http://localhost:8150
WG_HOST=0.0.0.0 python3 server.py → expose on the tailnet
MB_TOKEN=mbt_… python3 server.py  → enables the generator tab (MODELBEAST bearer token)

No build step: stdlib server + three.js from CDN. Heavy lifting = local headless Blender (blender_ops.py, tested on 5.1.2; override path with WG_BLENDER).

What it does

  • Library panes: bodies (scans library/bodies/ + ~/Documents/anatomy + thriftgod's web/assets/models), garments, generated images, finished outfits. Upload via file inputs.
  • Stage: orbit viewer; FBX auto-converts to GLB (cached in .glbcache/); HUD reads tris / height / rig state (bones + clips); first clip auto-plays.
  • Body ops: scale-to-height (bases arrive 1.0m tall — normalize to ~1.72m); decimate-keep-weights (the SAFE local path for rigged meshes — never farm /finish).
  • Rigid attach (tier 1): hats/bags/shoes → pick a bone, slide offsets, preview live. Bake permanently via the fleet /rig endpoint (m1ultra :8011) when happy.
  • Deforming FIT (tier 2): weight-transfers the rigged body's skinning onto a garment mesh (Blender data_transfer, nearest-face interpolated, optional inflate-mm of air), parents it to the armature. FIT → wardrobe item = garment+skeleton GLB (reusable); fit → dressed glb = body+garment in one.
  • Assemble: body + ticked fitted garments → one dressed GLB in out/ — drop straight into thriftgod / djsim / procity, or publish to 3GOD.

Generating NEW clothing (the pipeline, $0 on MODELBEAST)

  1. flux (flux_local, Klein) — product-shot prompt template: garment laid flat, white bg
  2. cutout (bg_remove_local) — the biggest quality lever before 3D
  3. then ONE of:
    • → rigid 3D (trellis_mac, ~5 min): hats, shoes, bags, glasses — bone-parent these. NOT for floppy cloth: reconstruction eats thin geometry (fleet traps ledger).
    • → hanging texture: flat garment PNG for rack planes (djsim fittings.js garment({image})) and the paper-doll wardrobe. Flat clothes love this route.
    • deforming wearables: model/retopo against the base body (or socket-cut a clothed torso, character_kit_modular style), then FIT. Never raw-gen these.

House rules

  • Bases (anatomical models) stay in the library. Only dressed outfits ship into games.
  • FIT requires a rigged body. Unrigged base → rig first (MIRPAMO on ultra, or Mixamo).
  • One skeleton (mixamorig) across the fleet: any garment fitted on one body fits every body on that skeleton, and every clip in the bank drives it.