The record is the control surface
Parametric modelling is most useful when a variation expresses a decision. You might want a taller landmark, a quieter palette or a consistently weathered courtyard. Start by describing that intent, then inspect the selected piece's knob schema. Each record defines its own supported names, defaults, choices and numeric limits. A control named tallness on one object does not imply that every object accepts it. Guessing familiar parameter names can produce invalid requests or a shape that never matches the intended scene.
Workshop lantern is a practical starting record. Existing export proof used its coal-ember colourway, derelict wear and a tallness value of 1.18. That is an observed sample configuration, not a universal prescription. Check the live record before reusing those settings. Quench barrel has a different set of useful decisions; do not paste the lantern configuration into it blindly. Read each field's description and allowed values, and keep a copy of the defaults so you can compare the change against a known starting point.
Change one thing and observe its cost
Turn one control at a time during the first experiment. Look at the object from the intended camera, not only from an attractive close-up. A taller lantern may improve a landmark silhouette while making its attachment look awkward beside a doorway. A wear setting might alter geometry rather than merely recolour a material. Compare bounding dimensions and measured triangles after each change. Screenshots are useful notes, but the chosen numeric values and the piece identity are what let another person reproduce your result.
Keep a small variation sheet with a baseline and two alternatives. Write the purpose of each alternative in ordinary words: more visible at distance, less bright beside the player, or consistent with a neglected yard. Avoid generating dozens of arbitrary configurations before testing any of them in context. The aim is to make an art decision legible. If a control cannot provide the shape you need, preserve that limitation and request the missing capability rather than exaggerating what a subtle scale change achieved.
Some decisions belong to the whole kit
A kit's usage contract distinguishes shared settings from local ones. In Foundry yard, wear is a scene-wide decision for parts that expose that knob; colourway can vary locally. Pick the wear value once, apply it consistently and then adjust individual colourways for hierarchy. This creates variation without making the assembly look like unrelated assets from different worlds. Structural placement also follows the kit's four-metre grid. Knob tuning does not replace the assembly contract or justify arbitrary changes to the scene scale.
Maintain a placement manifest containing each piece ID, position in metres, rotation, scale and exact knob values. Add the triangle count you actually measured for the variant. The shared coordinate contract is Y-up with positive Z forward, with origins resting at Y zero and centred footprints. When terrain is uneven, sample the height instead of using a knob as a workaround for ground penetration. Keep environment placement decisions distinct from shape parameters, otherwise a future rebuild becomes hard to reason about.
A snapshot is not the original live factory
The source factory can build a variant from its supported parameters, but the Use it ES module exports a static snapshot of the current object. Its default createPiece function reconstructs geometry and materials already captured with the current knobs and visible parts. Calling that downloaded function with imaginary new controls is not a supported way to retune the original piece. To obtain another baked variation, change the supported controls in the preview and export a new snapshot with a distinct, recorded filename.
The GLB tab similarly exports the exact object on the table and reloads it with GLTFLoader before saving. Existing barrel and lantern round trips checked specific samples, not all combinations. The older Hedge pilot record is a useful warning: technical checks can exist while publication is withheld and distribution rights remain unclear. Inspect its selected release state rather than treating a successful test as permission to publish. Unity tooling remains untested, and a valid binary is not proof of an engine-level result.
Automate discovery, not assumptions
Read prompt.txt before asking an agent to tune a piece. Discover the actual record, fetch its detail and request a variant with a plain-language want. Use the returned knobs rather than invented names. The HTTP tool bridge accepts get_variant with id and want, while the CDN has its own documented parameter rules. Unknown or invalid CDN knob values return an error, and nondefault file-backed variants are currently unavailable. A failure should be reported as a limitation, not quietly replaced with a default that pretends to satisfy the request.
Close the loop by checking the result visually and recording which calls succeeded. Do not put an entitlement key into a public URL or shared prompt. Save the variant's identity, settings, measured budget and licence findings beside the local file. If the desired shape is missing, report that need honestly; the current reporting bridge is process-memory storage, not a durable fulfilment promise. A good parametric workflow ends with a small set of intentional, reproducible alternatives and a clear boundary around everything that has not been tested.
Real records used in this guide
- Workshop lantern
workshop-lantern - Quench barrel
quench-barrel - Hedge · inspect release status
kit_hedge - Foundry yard
foundry-yard
Check the selected version’s release, rights and access before using any file.