unity-game-3d-modeling

Unity game 3D model creation

Turn the approved visual direction into traceable, importable, runtime-verifiable 3D models. First read3D modeling tool workflow, then decide whether to use @Unity, a generative vendor, or an approved DCC MCP.

Inputs and boundaries

• Requires an existing Visual Bible, purpose, viewing distance, units, axes, Pivot, topology/polygon budget, material slots, LOD, collision, export format, license, and target Unity project.
• When model specs, a unique Unity project target, required Pipeline commands, or modification authorization are missing, you may first output read-only spec suggestions marked with assumptions, but the write state remains BLOCKED, and suggestions must not be treated as approval.
• Model briefs, external vendor or DCC selection, payment and upload, silhouette/interaction boundaries, UV reconstruction, and vertex order changes must all first go to $unity-game-grilling, generating an approval record bound to the current model candidate; when unapproved, affected writes or external calls are prohibited.
• Only responsible for geometry, topology, normals, UV version freezing, LOD, Collider, model import, and Prefab self-checks; PBR textures go to $unity-game-3d-texturing, and final verification goes to $unity-game-qa-performance。
• Rigging, animation, and VFX do not automatically enter this role just because of “3D”.

@Unity and DCC routing

1. Select the unique Editor according to the current unity:unity-cli rules, and read the actual command and parameter Schema. Stop writing when Unity is unstable, the command does not exist, or parameters do not match.
2. For simple, modular, low-poly, or graybox geometry, prioritize the project-installed ProBuilder API, and generate reproducible structures through discovered project Pipeline commands; do not guess command names.
3. When AI candidate models are needed, first select a user-approved generative vendor. Only after explaining to the user the vendor, cost, uploaded data, license, and expected format and obtaining approval may an asynchronous generation task be submitted; save the task ID and query status according to the vendor protocol without blocking and waiting.
4. When local FBX, OBJ, GLB, or glTF already exists, process approved paths in the project through AssetDatabase or discovered project Pipeline import commands; do not describe an image import command as a model importer.
5. When complex character topology, precise UVs, sculpting, retopology, or advanced baking requires DCC, use only a local DCC MCP that the user has approved and whose capabilities have been discovered. If capabilities are missing, BLOCKED, and do not falsely report completion.
6. Vendor output, ProBuilder output, and DCC output are all only candidates; during R&D they must pass spec, license, and Unity Editor/PlayMode gates; approved platform device gates can only be executed at G3 after G2 PASS .

Scene micro-loop

1. Freeze the model brief, Visual Bible version, asset ID, and acceptance matrix.
2. Generate a blockout, output silhouette, proportion, and scale evidence at fixed camera positions, and hand it to visual and gameplay review.
3. After user confirmation, refine geometry, topology, normals, UVs, material slots, LOD, and collision; when changing an approved silhouette or interaction boundary, return for confirmation.
4. Record the model recipe, tool/vendor versions, prompts, parameters, source file hashes, and derivation relationships.
5. Serial access to Unity: for external models, inspect ModelImporter, scale, axes, and Pivot; native ProBuilder Mesh/Prefab does not fabricate ModelImporter evidence. Both paths check material slots, LODGroup, Collider, Prefab references, and runtime warnings.
6. Output turntable, wireframe, collision, LOD, and target scene screenshots; after self-check passes, hand off to the texture role or independent QA, without self-approval.

Security and write rules

• External generative vendors are disabled by default. Any vendor call, image upload, and paid generation must obtain user confirmation per task; keys may only be stored in secure storage provided by the vendor or system, and are prohibited from being written to repositories, logs, or task records.
• Only upload user-approved project files; prompts and outputs must record provenance, licensing, and content risk.
• If DCC MCP supports arbitrary code execution, treat it as a high-risk capability. Display and approve scripts before execution; scripts may only allow DCC APIs, math, and mesh operations, and are prohibited from OS commands, networking, environment variables, arbitrary file reads, and dynamic imports.
• Original sources are read-only; modifications are written to versioned derived files; for the same DCC source, model asset ID, Unity project, and export target, only one write agent is allowed at a time.
• Before overwriting, deleting, rebuilding UVs, or changing vertex order or skinning information, create a checkpoint and obtain confirmation.

Delivery

Deliver versioned source files, runtime models, Prefabs, model recipes, SHA-256, licensing, UV hashes, import settings, LOD/Collider metrics, and Unity evidence. Models must use the registered branch matching the asset type, and it is prohibited to falsely fill in image fields such as TextureImporter/Sprite to pass the contract.