Scenario Patina Retexture

Scenario PATINA retexture

Overview

A mesh whose materials are flat colors or placeholders (an image-to-3D result, a whole diorama) becomes a PBR-shaded asset in three moves: group its materials into physical surface families, generate one seamless PATINA material per family on Scenario, and wire the five maps into Blender materials with vertices, faces, and transforms left unchanged. An optional film renders the original and the retextured scene along one camera path with the same lights, exposure, and cut, so the material response is the only thing that differs between the two panels. The film is rendered locally to present the 3D deliverable, never generated on Scenario, so the skill's output type stays 3D.

PATINA is Patina AI's material family on Scenario (tag sc:texture). This skill runs PATINA Material, the prompt-to-material member; the flat-texture members (Image to Maps, Material Extract) belong to scenario-textures. Repainting a whole mesh with a 3D-to-3D texturing model is the scenario-3d lane; this one keeps per-material control and editable Blender shaders. The agent's own steps stay on MCP; the bundled scripts (Blender 4.2 or newer, Python 3 with Pillow and numpy, ffmpeg) do the local repetition and never call Scenario. Connection and the core loop: the scenario skill. If a sibling skill named here is missing from your available skills, ask the user to install it (npx skills add scenario-labs/skills --skill <name>); unattended, proceed from tool schemas and flag the gap.

Quick reference

Material families

Read inventory.json, not the scene. Group materials by what the surface physically is (plaster, cedar, terracotta, glazed ceramic, brass, painted steel, glass, canvas, asphalt, foliage), reusing one family across color variants: the shader keeps each original color as a tint under the PATINA basecolor by default, so one plaster set serves cream, ochre, and gray walls. Split a shared color that sits on different surfaces (the same green on a canvas awning and a painted sign) with an object_overrides entry keyed by object-name prefix. A 41-material diorama needed 14 families; expect one job per family. Where the mesh already models bricks, roof tiles, or planks, prompt for the material of one element (fired clay, weathered cedar), never for the pattern: the geometry supplies the structure and a patterned map doubles it.

Generating one set per family

model_schema_get on the discovered id is the contract; the names below held at authoring time. prompt (required, 2048 characters) describes a flat, evenly lit, seamless physical surface with no objects or signage. maps is an array even for one entry (a bare string is ignored); keep the default of all five. width and height run 512 to 2048 in steps of 16, 1024 by default, and tileSize (128, about 1024 px) follows them: 256 for a 2048 set, or the repeat window no longer matches the texture. upscaleFactor 2 or 4 enlarges the predicted maps only, not the base texture. tilingMode restricts the repeat to one axis for planks or corrugation. numOutputs returns up to 4 variants of one prompt, each priced. enablePromptExpansion is on by default: turn it off when the prompt is deliberate. Set seed per family and keep it in the manifest so a family can be regenerated identically.

Keep dry_run and wait at the top level of model_run, beside model_id, team_id, and project_id; only model inputs belong under parameters. Price the exact payload with dry_run=true (a cost estimate, not parameter validation), confirm the budget (families times cost), then launch every family with wait=false and one jobs_wait over all the job ids (32 per call), re-called with pending_job_ids on timeout rather than answered with a second model_run. On a transport error, jobs_list before re-running: the job usually landed.

With the default five maps and numOutputs 1, a completed job carried six asset ids at authoring time: the base texture (metadata.type inference-txt2img-texture) and one asset per map, labeled texture-albedo, texture-normal, texture-smoothness, texture-metallic, and texture-height; numOutputs multiplies the set. Treat the metadata.type values read back with asset_get as the contract and map them to the five roles, never the order. The roughness request comes back labeled smoothness, and at authoring time the values were roughness (a brushed brass map read darker than a matte gray one), so the label is the trap, not the data: asset_display that map for a family whose finish you know before touching roughness_is_smoothness in the manifest, which inverts it when true. asset_download each map (PNG by default) into textures/<family>/<role>.png, and record prompt, seed, job id, asset ids, scope pair, and billed cuCost under the manifest's provenance.

Applying in Blender

blender --background --factory-startup --python scripts/inventory.py -- model.glb work/ imports the mesh (GLB, glTF, OBJ, or FBX) or opens a .blend, saves a packed work/Before.blend, and writes work/inventory.json. Write work/materials.json mapping every material name to a family and every family to its five maps (the manifest reference has every key and default), then run blender --background --factory-startup work/Before.blend --python scripts/apply_materials.py -- work/materials.json. It validates the manifest, projects a dedicated PatinaUV layer along each face's dominant axis at object scale so tile_span means meters per repeat (a mesh shared by linked duplicates is made single-user first), builds one Principled BSDF per original material and family, packs the images, and asserts the geometry hash is unchanged. The .blend is the deliverable: a glTF export flattens the calibrated shader graph (the exporter carries only direct texture links), so bake before exporting to an engine. Open the result or render one still before spending render time on a film.