blender-editable-3d

From reference to editable Blender model

Give the user a 3D project in which parts can be selected, further modified, saved as, and exported. The AI understands the reference and writes Blender Python, and Blender builds the geometry, materials, and scene. Do not treat rendered images as 3D files, and do not turn this case's vehicle model, object count, and dimensions into a universal template.

1. Clarify input and goal

• Review the images, design drawings, or existing models provided by the user. When a text concept is given, you may directly design a reasonable stylized model and explain the design assumptions adopted.
• When the user wants to reproduce a case and replace the subject, keep the working approach of "reference understanding, independent parts, editable project, actual modifications, export verification" and redesign the subject. Do not copy the original case's parts list.
• Clarify the appearance style, main dimensions, parts that must be independent, and intended use. General proportions, color scheme, and display angles may be chosen on your own; missing information that would change the object's identity or require exact replication should be clarified first.
• Distinguish shapes that can be confirmed from the input, annotated dimensions, unknown back sides, and design completions. When multiple views conflict, prioritize the dimension source specified by the user and record the actual trade-offs.
• When there is no original drawing, a concept explanatory image may be added, but it must be accurately labeled as a design aid or supplementary explanation. Do not claim to have modeled from a drawing first when in fact the drawing was reverse-engineered from the finished model.

2. Check the environment and existing assets

• Check the actual Blender path, version, and existing projects. A temporarily run Blender does not mean it is installed; install software only when the user authorizes it.
• Prefer Blender Python/CLI or the existing Blender API. MCP can carry scripts, but it is not a necessary dependency of this workflow; avoid repeatedly initializing desktop control solely for modeling.
• Use --python-exit-code 1 to run scripts, and when exceptions occur, check the logs and exit codes. When sandboxing causes startup failure, use the host's permission mechanism; do not ignore the failure and then report success.
• Preserve the user's original model and unsaved changes. Use a separate directory for new cases; save subsequent modifications as new versions, and do not write to the same project from both the foreground and background at the same time.
• First check reusable assets and their licenses. If downloaded models or external generation services are used, explain the source and their actual contribution, and do not pass them off as original scripted modeling.

3. Break the appearance down into editable parts

• Write a brief parts list in the project, mapping key reference features to specific geometry and object names. For example, a furniture piece's cabinet body and drawers, a robot's torso and sensors, a tank's hull, tracks, wheel assemblies, and turret.
• Use Collections and, where necessary, Empties to express assembly relationships. Split into objects only the parts that need to be independently selected, modified, or exported; repeated parts may share mesh data while retaining separate object control.
• First establish the main silhouette and proportions, then add details, bevels, and materials. Choose primitives, curves, or direct meshes suited to the shape, and do not force all objects to use the same geometric representation.
• Set clear units and axes. Distinguish between the object origin, local coordinates, parent transforms, and the final visible dimensions; modifiers may cause the measured dimensions to differ from the designed dimensions.
• Check face orientation, key seams, and attachment relationships. Look at the main view and orthographic views first, correct obvious proportion or normal issues, then output all presentation images.

4. Save the base project and make actual modifications

• When the user explicitly requests modifications or a demonstration, first save the base .blend, then reopen this file to make modifications; when there is no modification request, deliver only the base project within the current scope.
• Read dimension modification and verification, and translate the natural language requirements into the specified objects, dimension changes, fixed anchors, and attached accessories that follow.
• Modify only the requested objects or shared materials. Before modifying the geometry of a single duplicated part, check whether the mesh is shared by multiple objects; when an independent modification is needed, first copy the target's data to avoid other objects changing along with it. When lengthening an axial part, check the diameter and the fixed end; when moving a bracket, check the sensor on it; when enlarging a box body, check the position of the lid.
• Save the modified version .blend. When it is necessary to prove the version's origin, record the base file digest in the modified version; do not call two independently generated similar models a modification based on the original project.
• Keep the same presentation cameras for the base version and the modified version, to avoid exaggerating the effect of modifications by changing the viewpoint, cropping, or lighting.

5. Export, verification, and delivery

• Deliver the native .blend, GLB, and a small number of multi-angle renders according to the current requirements. Deliver both the base version and the modified version at the same time only when the user explicitly requests keeping the pre- and post-modification versions; when the user only requests a single model or a local edit of an existing project, follow their scope.
• Export only the target model in the GLB, without mixing in the studio floor, lights, or auxiliary objects. Import it back into an empty scene, and check the independent parts, names, and key geometry; do not describe a successful Blender round-trip as meaning all engines' materials are consistent.
• Reopen the final native project, and check that objects are selectable, key dimensions and color schemes meet the requirements, and accessory positions are correct. Do not use mere file existence or object count as evidence of success.
• Check the final render. Valid geometry, similar appearance, and production readiness are different judgments; truthfully explain any UV, rigging, collision, manufacturing tolerance, and print verification that has not been done, and do not automatically expand the work.
• Save a readable initial viewpoint and display mode. Color demonstrations may use SOLID's material colors, but that is not the same as the true render of the node materials; when material judgment is needed, check the material preview or render.
• Provide an actually openable file link, and briefly explain which parts can be modified, how to find them, what was changed between the two versions, and the checks that actually passed.

Scope boundaries

Exploded animations, assembly demonstrations, Blender interface screen recordings, character rigging, and print checks are all separate follow-up requests. Do not generate these by default just because the model has independent parts. When the user only requests a tutorial, analysis, or a packaged skill, keep the existing model read-only.