What the Blender Skill Covers
The parent skill handles headless Blender inspection, FBX/GLB conversion when authorized, native rendering, procedural and terrain generation, and bpy automation. It routes specialist work to focused references instead of treating every task as a model export.
For Texture-Only Work, Blender Inspects—It Does Not Rewrite the FBX.
Its role is to inspect exact objects, materials and UVs; support native-resolution masks; diagnose PBR inputs; bake only when authorized; and produce controlled native proof renders. The browser comparison reads the original FBX directly.
Headless success requires actual artifacts or structured markers, not exit code alone. Final visual work requires production-quality assets and full-resolution QA, not recognizable stock primitives.
Texturing Workflow
A reusable procedure under the Blender skill for texture creation, refinement, and troubleshooting. Read this before changing maps or building a texture-review viewer. The scope agreement, not the tool's capabilities, determines what may change.
Natural triggers
“Better textures”, “refine textures”, “only texture mesh/object X”, “leave the rest alone”, “don't edit FBX”, “use the UVs”, “new-ish engine”, “new engine”, “match yellow/paint”, “less scratches/wear”, “smoothness/roughness”, “metallic/AO/emissive/packed map”, and “interactive texture preview”. Route these phrases here even when Blender is not named.
1. Agree on scope before edits
- Identify the source asset, exact object names, intended maps/channels, target engine/shader, desired appearance, and delivery format. Distinguish creation, refinement, and troubleshooting.
- Write an explicit allowlist of mutable files, objects, UV regions, and channels; everything else is protected. Clarify genuinely ambiguous scope before mutation.
- For texture-only work, the FBX is strictly read-only object/UV reference: NEVER edit or re-export it, including to simplify browser delivery. Import into a disposable inspection scene only; do not save model changes over the source.
- Creation requiring new UVs, rebaking, material reassignment, or model changes needs separate explicit authorization; do not silently extend a texture-only brief.
- Preserve originals and recoverable revisions. Record SHA256, dimensions, bit depth, color spaces, materials, and source filenames before work.
2. Prove object and UV isolation
- Match the literal object name, not its numeric index or a fuzzy name. For the engine example the target is exactly
1. - Inspect all meshes using each atlas, UV sets, material slots, repeated/wrapped UVs, and shared/overlapping islands. Rasterize triangle coverage at native texture resolution, with verified UV/image Y orientation.
- Compare the target mask with every non-target mask. Use geometric UV union intersections where possible; raster overlap alone can miss subpixel boundaries. Record island distances and filtering/mipmap risk.
- STOP and explain when shared pixels or sampling footprints prevent isolation. Ask for a narrower edit or separately authorized UV/material changes; never claim object isolation while another object can change.
- Composite candidate pixels only inside the approved target mask. Preserve every other object's pixels, atlas borders, lettering, and non-target channels. Do not dilate into protected pixels or resize the atlas without authorization.
3. Establish the material contract
- Inspect documented source shader settings or ask the artist for channel meanings and normal Y convention. Never assume a generic ORM packing or infer semantics solely from a channel's appearance.
- Record confirmed asset-specific layouts separately from universal workflow rules. See the engine case; its R/G/B/A mapping is NOT a universal default.
- Keep unknown packed channels untouched. A neutral-roughness diagnostic viewer may be useful but must be labeled a diagnostic approximation, not a faithful material evaluation.
- Treat packed data, normal, metallic, AO, smoothness, and roughness as linear/non-color data. Use base color as sRGB. In Blender use
CHANNEL_PACKEDalpha mode when independent packed RGB/A would otherwise be affected by alpha handling. - Roughness = 1 − smoothness. Validate the consuming GPU shader's channel expectations, UV set, texture orientation, numeric factors, emissive interpretation, and normal Y; never merely attach a packed file to a mismatched input.
- For Three.js MeshStandardMaterial, stock metalness reads B, roughness G, and AO R. Build transient viewer maps with the documented source channels routed accordingly; retain original delivered packing. A scalar emissive mask may need replication into RGB and documented color/intensity. Verify the exact Three.js version's AO UV expectations.
4. Make the smallest justified visual change
- Start from the user's appearance target and existing color. “New-ish/new engine” means restrained clean paint with minimal or no scrapes, scratches, chips, grime, or wear—not generic distressed metal. Preserve the existing yellow when requested.
- Do not add wear to demonstrate effort. Separate base-color mottling from roughness response and lighting artifacts. Change one approved component at a time and retain a reversible baseline.
- Generative atlas edits are candidates only: preserve native detail, island boundaries, labels, and dimensions by masked compositing. Disclose any resized generated contribution.
- For channel-only revisions, copy the other channels exactly. Keep previously accepted or merely retained maps unchanged; distinguish those two statuses.
5. Verify pixels and bytes
- Compare decoded before/after pixels at native dimensions and bit depth. Record changed pixels per channel, changed pixels outside the approved mask, and changed pixels under every protected object's UV coverage.
- Require zero changes outside the mask and zero changes in non-target channels. Hash unchanged textures and source FBX before/after; require exact SHA256 equality. Pixel equality and file equality are different evidence—report both where relevant.
- Record map layout, operations, mask hash, filenames, hashes, dimensions, overlap evidence, and exceptions in a machine-readable manifest. Reopen saved output; an in-memory result or a zero process exit is insufficient.
- Do not substitute plausible counts for execution. If evidence is missing, say unverified and stop short of a preservation claim.
6. Review the real material interactively
- Load the original FBX bytes directly with Three.js FBXLoader for read-only texture comparisons; no GLB conversion or replacement FBX export. Viewer-only material assignment is allowed without changing source bytes.
- Hold camera, lights, environment, exposure, tone mapping, shader, normal, and all non-target maps identical across before/after. State whether “before” means original source or previous revision. Avoid conflating sequential color and smoothness experiments.
- Provide before/after selection, full assembly and exact-object isolation, orbit, zoom, and wireframe. Show map/channel assumptions and revision labels; disclose baked AO versus renderer occlusion and browser versus target-engine differences.
- Exercise the actual live controls in a real browser. Verify model/texture loads, meaningful camera movement, before/after switching, isolation, wireframe, desktop/mobile overflow, and console errors. Capture screenshots of the loaded subject, not just the page shell.
- Use an isolated browser context when the real profile is locked. Do not name a local Python script
inspect.py; it shadows the standard library and can break inspection dependencies. - Technical QA is not artist approval. Record explicit visual acceptance only when the artist actually gives it.
7. Package and publish with evidence
- Deliver standalone edited textures, protected supporting maps as needed, a ZIP, revision manifest, and original/revision recovery pointers. Keep source FBX read-only.
- Load the ForgeMedia skill for authorized uploads. Catalog textures, ZIP, manifest, and preview; read back the exact records and verify downloaded storage bytes/hashes before claiming delivery. A returned upload ID alone is not verification.
- Load Share Preview and the ForgeFX design system for branded review pages. Inspect locally first, publish the clean URL, verify public content and actual viewport, and deliver the URL plus screenshot. Explain that unlisted link-accessible previews are not private.
- Report what changed, what was preserved, pixel/hash verification, preview limitations, and approval status. Never overwrite the only recoverable previous revision.
8. Learn as Brandon teaches
- Treat direct corrections as workflow evidence. When the user authorizes or nudges continued learning, update this procedure or its asset-specific reference as part of the current work, not a promise for later.
- Separate confirmed constraints, tested observations, hypotheses, experiments, and artist approval. Do not promote an experiment into a default or an unapproved look into an approved baseline.
- Put general lessons here; put per-asset packing, masks, numbers, and art direction in the linked case reference or task manifest. Never globalize a specific channel layout.
- If useful learning emerges but update intent is unclear, offer the targeted skill update. Do not change global persona/runtime instructions or another profile.
- Consolidate overlapping Blender guidance through links; validate discovery and file links, log changes, and commit only authorized paths using the Learn workflow when invoked.
Completion gate
Scope recorded → immutable source hashed → UV isolation proven → channel contract confirmed → minimal masked edit → pixel and byte checks passed → equivalent interactive comparison exercised → exact catalog/storage delivery verified → artist approval separately recorded.
Related Blender references: headless pitfalls, FBX inspection, final visual quality (available in the skill package). Blender owns inspection, masks, material analysis, baking when authorized, and native proof rendering; a browser viewer is review evidence, not permission to alter the source model.
Engine Mesh 1 — Asset-Specific Teaching Example
This is a historical experiment and a confirmed material contract, NOT a universal preset or an artist-approved look.
Confirmed by Brandon
- FBX is strictly read-only UV/object reference. Never edit or re-export it for texture-only work.
- Target the mesh named exactly
1; preserve all other objects' atlas pixels. - New-ish engine: restrained clean paint, minimal/no scratches or wear, existing yellow maintained.
- This asset's packing: R metallic, G ambient occlusion, B emissive, A smoothness. Do not transfer this layout to other assets without confirmation.
Revision history and evidence
The initial base-color refinement softened mottling only. The initial diagnostic shader used neutral roughness while packed meanings were unknown; that was not evidence of the asset's intended material response.
The subsequent alpha-only experiment changed masked alpha from 127 to 108, corresponding to smoothness 0.498 to 0.424, and roughness 0.502 to 0.576. Those are rounded normalized values from the manifest, not recommended settings. Both views retain the prior refined base color; only smoothness differs in this comparison.
The existing manifest reports 1,318,956 target/changed alpha pixels, zero changed RGB bytes, zero outside-mask alpha changes, and zero target/non-target raster overlaps. It records geometric separation from the other UV unions. Base color, normal, and FBX were retained. This procedure-writing task did not rerun texture processing and does not independently recertify that earlier evidence.
- Source evidence:
/Users/forgebot/forge-artifacts/engine-mesh1/manifest.json - Recoverable prior revision:
/Users/forgebot/forge-artifacts/engine-mesh1/versions/pre-smoothness/ - Existing interactive comparison: https://preview.forgefx.dev/brandon-engine-mesh1
- Source FBX SHA256 recorded in manifest:
de4dc745c9a0142a8295f50dba5910b5b0712caf8485b4e19a95f2c888af4941
The viewer uses transient RGB = source G, 255 − source A, source R for AO/roughness/metalness, plus source B replicated for emission. Data maps remain linear; base color remains sRGB. Delivered packed channels retain the asset's original contract.
Approval status: no explicit Brandon visual approval is recorded in the supplied thread. “Verified isolation” does not mean “approved appearance.” Future instructions may supersede this experiment; preserve its provenance rather than rewriting it as a universal rule.
What Was Learned
Read-only FBX is a hard constraint, not a preference. Object-local means UV-local and overlap-tested. New-ish means clean paint rather than invented wear. Packed channel meanings come from the asset's documented contract, not generic conventions. Pixel and SHA256 evidence establish preservation; artist approval is a separate decision.
How This Keeps Learning
Direct authorized corrections update the procedure during the work. General rules stay in the procedure; asset-specific mappings and experiments stay in the case reference. Hypotheses remain labeled, unapproved looks remain unapproved, and useful lessons with unclear update intent prompt a targeted offer.