3D Modeling with LLMs: A Practical Test Using *Yingzao Fayuan*

1. Origin: A Simple Instruction, a Compound Challenge

Using large language models for 3D modeling is moving from demo-level to production-grade. My evaluation method is straightforward: give the model an instruction that would naturally come up in real work—“Build a bianzuo hall in a scripted 3D modeling tool as described in Yingzao Fayuan“—and then observe its performance across a full generate–check–revise–recheck cycle.

The instruction looks simple but layers four distinct challenges:

1. Classical terminology comprehension: bianzuo, xuan, ridge column, golden column, chuan, fang—these terms rarely appear in modern general-purpose corpora. The model must accurately reconstruct their structural meanings.
2. Construction-system knowledge: Traditional timber framing has strict conventions for component proportions and column positioning. Get it slightly wrong and “it’s just not that thing.”
3. Geometric reasoning: Translating textual specifications into coordinates, cross-sections, and spacing.
4. Code generation: Producing a runnable, readable, modifiable modeling script.

A failure at any layer is immediately visible in the rendered image. This is exactly why modeling tasks are better suited for model evaluation than plain text tasks: errors are rigid—there’s no room for “close enough.”

Past experience shows that most models can produce a model with “good bones but plenty of errors” in the first round—overall form is correct, but column-beam relationships and detail dimensions are often wrong. The real watershed appears in the revision phase. When you ask the model to raise a beam or increase the density of a xuan frame, it often hits the wrong target: you ask it to modify the main beam, and it moves a golden column; you ask it to adjust spacing, and it rearranges the entire roof. After several rounds, costs accumulate with nothing to show, and the model may end up worse than the initial version. So the core question for this evaluation is simply: Is the iterative revision phase stable or not?

2. Why Use the Bianzuo Hall as the Test Case

Choosing traditional construction as a benchmark offers three advantages.

First, the terminology is sufficiently specialized. Yingzao Fayuan documents Jiangnan construction methods. A bianzuo hall refers to a hall where the beam frame uses the bianzuo method (rectangular-section large timbers), as opposed to the yuanzuo (round-section) method. Ridge columns, golden columns, eave columns, main beams, mountain-boundary beams, chuan, fang, and purlins each have their proper positions. These terms appear infrequently in general corpora, making them effective at testing a model’s specialized knowledge rather than its ability to recite common tutorials.

Second, structural relationships are strict. Traditional halls follow the jianjia system: a defined number of bays and roof-frame tiers, symmetric column positions, and tiered beam elevation. Errors can’t hide behind “looks about right”—whether the column grid of the central bay and side bays is symmetric, whether ridge purlin height decreases tier by tier, whether the xuan frame is structurally separated from the main beam frame—all have objective answers.

Third, the task scale is moderate. A bianzuo hall contains dozens to roughly a hundred components. A single conversation can complete the initial build while still supporting multiple rounds of revision testing—not so large that it blows the context window, not so small that it loses evaluation value.

Test cases of this type—specialized knowledge + strict structure + moderate scale—deserve to be preserved as standard benchmarks: whatever new generation of models arrives, retest with the same cases rather than drawing conclusions by feel.

3. Evaluation Framework: Three Dimensions of Model Quality

Dimension	Key Inspection Points	Typical Failure Signals
First-pass generation	Script runs, systematic naming, valid structural relationships	Overlapping/intersecting components, script errors out
Terminology understanding	Structural meanings and positional relationships of technical terms	Bianzuo/yuanzuo confusion, column hierarchy inverted
Instruction following	Modifications precisely hit target components	Changing A affects B, unmentioned components altered
Cost efficiency	Effective interaction rounds to reach goal	Multiple wasted rounds, drifting further from the initial version

Dimension 1: First-pass generation quality. Don’t look at “does it look right”—look at three things: Can the script run directly? Can component names convey category and sequence number? Are structural relationships valid (columns land on the ground, beams rest on columns, purlins sit on beams)?

Dimension 2: Terminology and construction-system understanding. Test with follow-up questions: “Where does the difference between bianzuo and yuanzuo show up in the components?” “Which layer of the beam frame does the mountain-boundary beam occupy?” If the model answers correctly, subsequent revisions have a shared language; if not, every revision is building on a faulty foundation.

Dimension 3: Modification instruction hit precision. This carries the highest weight. The method is to constrain modification instructions to the granularity of “only one component should change,” then verify item by item: Did the target component change as expected? Were unmentioned components left untouched? Is the script organized as a “local incremental change” or a “full rewrite”?

One additional practical technique: include effective rounds in your metrics. Going from the same initial version to the same target version, some models get there in three rounds while others spin for a dozen—the latter means real-world projects burn through API costs continuously, which is often more damaging than a gap in first-pass quality.

4. The Biggest Pain Point: Why Iterative Modifications Hit the Wrong Target

Breaking down revision-phase failures reveals four main causes—and most aren’t because the model “got dumber,” but because the interaction method gives it room to err.

Cause 1: Ambiguous references. “This beam” or “that column” in conversation is a dangling pointer to the model. If the initial script has twenty beams, “this one” is a guess. Guess wrong, and from your perspective, the model hit the wrong target.

Cause 2: Context dilution. After multiple rounds, early conventions—whether units are millimeters or meters, whether Z-axis points up or down, naming rules—gradually fade in attention. Then strange errors like dimension drift and coordinate-system flips start appearing.

Cause 3: Full-rewrite tendency. Ask the model to change one thing, and it habitually rewrites the entire script. During rewriting, parts that weren’t asked to change may also shift: variable names change, default values change, component order rearranges. On the surface you’re doing incremental edits, but in practice every round is a full regression.

Cause 4: Geometric baseline ambiguity. “Raise it a bit”—from the column top or from the ground? “Tuck it inward”—relative to the axis line or the column face? Modification instructions without explicit baselines are destined to be a coin flip.

5. Practical Methods: Getting the Model to Reliably Follow Modification Instructions

Countermeasure 1: Establish rules before giving commands. Put the component list, naming conventions, units, and coordinate system into a system-level prompt so they maintain high weight across every round:

[Construction context] One Jiangnan bianzuo hall, three bays, seven roof-frame tiers, beam frame uses bianzuo method (rectangular large timbers).
[Component list] Ridge column, golden column, eave column, main beam, mountain-boundary beam, chuan, fang, purlin... (with quantities and sequence numbers)
[Naming convention] Components uniformly named as <category_pinyin>_<two-digit sequence>, e.g., beam_da_liang_01.
[Units and coordinate system] Length unit: millimeters. Z-axis points up. Origin at the geometric center of the central bay floor.
[Task] Generate this round's script based on the above conventions; subsequent modifications output diff patches only. Unmentioned components must not be touched.

Countermeasure 2: Always use explicit component IDs. Instructions must not contain “this one” or “that one”—the target must be written explicitly, e.g., “Increase the cross-section height of beam_da_liang_01 by 10%.” The model’s hit precision with explicit IDs is far higher than with vague references.

Countermeasure 3: Restate first, act second. Require the model to output a modification plan before executing: which component, what parameter, and how to verify that other components are unaffected. Correcting a wrong plan on the spot costs far less than fixing a completed revision.

Countermeasure 4: Output patches only—never rewrite the full script. Include defensive validation in the script:

def apply_patch(scene, patch):
    """Apply only modifications explicitly declared in the patch; all other components are locked."""
    changed = {}
    for comp_id, ops in patch.items():
        target = scene.registry[comp_id]   # Unknown ID raises an error; no guessing
        before = snapshot(target)
        for op in ops:
            target.apply(op)               # Atomic operations: translate/scale/replace
        changed[comp_id] = (before, snapshot(target))
    return changed
# Example: increase only the main beam cross-section height by 10%, leave all else untouched
patch = {"beam_da_liang_01": [{"op": "scale", "axis": "z", "factor": 1.1}]}
apply_patch(scene, patch)

Countermeasure 5: Snapshot every round for rollback. Take snapshots of component properties before and after each modification. If a regression appears in a given round, roll back to the previous version rather than stacking more changes on top of a broken one. Version management here is structurally identical to its role in traditional software development.

6. Engineering Deployment: From “Can Build” to “Can Use”

Single-user conversational evaluation must ultimately be distilled into a reusable pipeline before it enters the productivity stage. The minimum viable form has four layers:

1. Document parsing layer: Organize construction literature into structured component parameter tables (category, cross-section, spacing, hierarchy) as the factual foundation for prompts.
2. Script generation layer: The LLM generates modeling scripts based on the parameter tables and naming conventions, with syntax and runtime validation performed first.
3. Render verification layer: Batch-render front views and section views; compare key dimensions manually or programmatically.
4. Version management layer: Each revision round produces a numbered snapshot supporting diff and rollback.

Teams looking to run this pipeline in the cloud can combine general-purpose cloud services: schedule script execution and batch rendering tasks on a container platform, store model files and version snapshots in object storage, feed modeling and modification logs into a logging service, and track per-round task success rates and regression rates through monitoring and alerting. These are all general cloud capabilities that can be assembled as needed.

7. Conclusion

The biggest takeaway from this bianzuo hall test isn’t whether “some model passes or fails”—it’s a more general conclusion: What determines whether an LLM can be used for serious modeling work is not the impressiveness of first-pass generation, but the controllability of the iterative revision phase. First-pass generation sets the floor; iteration quality sets the ceiling.

For domains like traditional construction, LLMs carry another layer of significance: turning construction knowledge dormant in ancient texts into verifiable, reusable 3D assets. Specific version evaluation conclusions will become outdated with each iteration, but “using rigorous test cases to establish a reproducible evaluation and modification workflow” will not.