Turn a Drawing Into an Editable 3D Model With GPT-6 Astra + Blender

Astra can build and revise a useful Blender model from a drawing—but the useful part is the editable scene, not the first render. In this local test, GPT-6 Astra authored and ran Blender Python to create a fictional survey rover, saved it, reopened it, and made three measured geometry changes plus a controlled material edit. Both GLB exports imported back into Blender with all 28 named mesh parts intact.

This was a guided reproduction with the earlier baseline available in the conversation. It was not a blind image-to-3D benchmark, a scan, or a test of photographs. Those distinctions matter when judging the result.

Left: Astra base scene. Right: the same saved scene after the edit. The mast is taller and wider, the side pod is longer, and only the roof assembly changes colour.

What we tested—and which model actually ran

The input was an original SVG drawing of the Fieldnote R1, a fictional four-wheel survey rover. The test required separate objects, procedural materials, an editable .blend, a portable GLB, five camera views, and exact follow-up edits.

The persisted Codex run settings identify this reproduction as gpt-6-astra, reasoning effort medium, at 2026-09-07T03:12:10.496Z (September 6 locally). The earlier baseline was created in a gpt-5.6-sol run. We retained that distinction rather than relabelling its files.

Inspect the extracted run settings. The extract contains the model, effort, timestamp, and turn identifier from Codex's saved turn_context record. It is run metadata, not a screenshot of the model selector. The scene's model label is supporting documentation; it is not the source of the attribution.

The drawing was helpful—and imperfect

The original reference is included unchanged. Its inconsistencies are part of the test.

The sheet supplies a recognizable design: graphite chassis, orange bumper, teal roof cells, four wheels, front cameras, mast camera, and a side sample pod. It labels a 1.60 m body length, a 1.05 m body width, and a 1.40 m wheel-to-wheel width.

But it is a concept sheet, not an engineering drawing. Its top view shows only two wheel shapes despite the written four-wheel requirement. Its views are not consistently scaled. The “0.70 m body” arrow runs from the wheel-ground level to the body top; it does not measure the shell's thickness. The rear, underside, suspension, and construction details are unspecified.

Astra used the written dimensions and four-wheel instruction as the controlling specification. It interpreted the 0.70 m arrow as ground-to-body-top height. Other dimensions, including the initial mast and pod sizes, were retained from the baseline to make the edit comparison useful.

This is a practical lesson for your own input: state which measurements take priority when the image disagrees with the text. Otherwise the model must make that decision silently.

The build prompt

The supplied prompt asked for an editable low-poly interpretation with separately named body, bumper, roof cells, wheels, hubs, axles, cameras, mast, pod, antenna, and status light. It also asked for native and portable files and five views.

Here is the essential instruction:

Create an editable low-poly interpretation at the stated dimensions. Keep the parts as separately named objects. Use procedural materials. Save an editable .blend, export a .glb, and render hero, front, side, rear, and top views. Do not use external 3D-generation services or downloaded models.

The original prompts are preserved verbatim. This continuation executed their build and edit requirements with the reviewed baseline already in context; the prompt text was not submitted as a separate isolated model call.

Astra wrote a new builder that starts with an empty scene. The resulting chassis is 1.60 m long including its front bumper and 1.05 m wide. The outer tyre span is 1.40 m. It uses Blender's metric unit setting with scale 1.

What came out of Blender

Hero, front, side, rear, and top views of the actual base scene. The four inspection views use orthographic cameras.

The native scene contains 28 rover mesh objects, excluding the studio ground, cameras, and lights. Four wheels and four hubs remain independent. The roof has separate cells. The mast, sensor head, camera lens, sample pod, and pod cap can each be selected by name.

The saved file opens with a positioned hero camera. Bevel modifiers remain available in the .blend. The materials use Blender shader values rather than external texture files. This is straightforward geometry that can be selected, resized, recoloured, animated, or replaced by a Blender artist.

The model is visibly an interpretation. The bumper is simpler than the wedge in the drawing, the surfaces are faceted, and small fittings are invented. A successful build does not mean every silhouette or detail matches.

The edit had to survive a file boundary

The follow-up prompt asked for a mast raised by 0.30 m, a camera head widened by 0.12 m, a pod extended by 0.20 m, and a roof changed from teal to orange.

For this test, the edit script reopened the saved base .blend. It recorded the source file's SHA-256 in the edited scene, then changed its geometry. It did not select an “edited” branch in a script and rebuild the entire scene.

The mast base stays fixed as the column grows. The head and lens move upward together. The pod grows symmetrically, so its cap moves 0.10 m to stay attached. The roof panel and four cells receive a new orange material. The mast head and pod remain teal.

Our verifier compares object names, mesh coordinates, locations, dimensions, and material values in the two saved files. Only the requested parts and their dependent attachments changed in those checks. It also verifies that the recorded edit-source hash matches the actual base file.

That is a stronger test than showing two attractive images. It tests whether an instruction affects the intended geometry while leaving other measured properties alone.

The earlier baseline passed narrower checks

Reviewing the original starter package exposed several claims that its verifier had not tested. Its three edit dimensions were correct, but that was only part of the brief.

The previous article's explanation of “30 tagged editable objects” was wrong: the ground inflated that tag count. The actual rover still had 29 mesh parts and an editable text label, so the files were useful, but the evidence did not support the wording.

These are findings about this particular reviewed reproduction. Astra saw the earlier work and benefited from additional review. This is not evidence that Astra beats the earlier model in a controlled comparison.

Native files and exports both matter

Both Astra GLBs were imported into empty Blender scenes. Each returned 28 meshes with the complete expected set of object names. That verifies basic export portability and object separation in Blender's importer.

It does not establish compatibility with every game engine, web viewer, or renderer. We did not test Unity, Unreal, material appearance in another renderer, collision, rigging, UVs, or animation export. The .blend remains the editing master; the GLB carries exported geometry with modifiers applied.

Open the full scene comparison. All 28 checks passed, covering edit deltas, edit isolation, names, source-file identity, units, selected dimensions, saved camera position, model labels, and GLB part names. These are scoped checks, not a certification that the model is production-ready.

How to try it yourself

Download the Astra starter ZIP, extract it, and open fieldnote_r1_base.blend. The source SVG, exact prompt record, scripts, evidence, and rendered views are included.

To reproduce the geometry without another model call, run these commands from the extracted folder with Blender on your path:

blender --background --python scripts/build_astra.py
blender --background --python scripts/edit_astra.py

On macOS, replace blender with /Applications/Blender.app/Contents/MacOS/Blender if needed. These scripts need no paid generation service. They reproduce the recorded workflow; rerunning them does not constitute a new Astra reasoning test.

To test Astra on your own design, supply a reference image, dimensions, and a list of separate parts. Ask it to save the first scene before making the edit. Require it to reopen that file, measure the change, and report what it could not infer. Capture that new run's model settings independently; the included evidence only attributes this recorded reproduction.

What Astra is doing here

The observable workflow is code-assisted modelling: Astra reads the design specification and authors Python; Blender executes that code, stores geometry, exports files, and renders images. The provided scripts do not invoke a native image-to-mesh generator or reconstruct a mesh from pixels.

For the broader setup, see the Kingy.ai Blender and Astra guide. The implementation uses Blender's Python API and glTF exporter.

Where the result stops being enough

A single drawing leaves hidden surfaces unresolved. This sheet supplies several views, yet still leaves the underside and rear undefined. The model fills those gaps with plausible shapes. An accurate reconstruction needs more information.

This was not a photo test. The experiment supports drawing-to-editable-3D through code. It does not establish photo reconstruction, texture recovery, or recognition of real products. A future photo test should use original photographs with known dimensions and evaluate views the model did not receive.

Editability is not finished asset quality. The wheels are separate, but there is no suspension rig. The surfaces are shaded, but there are no authored texture maps. The parts exist, but manufacturing tolerances, watertightness, printability, collision and deformation topology were not validated.

The reference itself can be wrong. Written dimensions overrode inconsistent silhouettes here. Better reference material would reduce the number of assumptions, particularly for organic or asymmetrical objects.

The model saw the baseline. This was an Astra continuation with earlier code and results in context. A blind comparison would need fresh sessions, equivalent instructions, multiple objects, and predefined scoring. We did not run that experiment.

FAQ

Did GPT-6 Astra actually perform this reproduction?

Yes. The persisted settings identify this continuation as gpt-6-astra with medium reasoning. Astra authored the reproduction scripts and used the local Blender executable to create, edit, render, and inspect the files. The earlier baseline remains attributed to its separate gpt-5.6-sol run.

Is this a one-click drawing-to-3D converter?

No. It is an agent-assisted Blender workflow using code, explicit dimensions, review, and validation. The original drawing was inspected visually and as SVG source; the supplied baseline was also available.

Can I edit the downloaded files normally?

Yes. The .blend contains named mesh objects, materials, and bevel modifiers. The GLB re-import test also preserved the part names and mesh count.

Can I use this to turn a photograph into an accurate model?

That was not tested. Start with multiple views and measured dimensions, and assess the geometry from angles absent from the input. Do not infer accuracy from one convincing render.

Is the output ready for 3D printing or a game?

It is a starting asset. Neither printability nor game-ready topology, rigging, collision, or engine integration was tested.

Was a paid generation service used?

No separate paid generation service or downloaded model was used. Modelling, rendering, exporting, and verification ran in local Blender. This does not imply that access to Astra itself is free.

The useful outcome is a reproducible, editable first model with an honest account of its assumptions. Here, Astra also repaired several weaknesses in the baseline and completed the requested edits without the earlier material side effects.