aDSL makes 3D spatial relations executable, then lets the critic repair them

On 18 August 2026, Rui-Huan Wang, Si-Tong Wei, Jia-Qi He, Heng-Yi Wei, Baoquan Chen, and Peng-Shuai Wang released Agentic 3D Creation via Joint Agent-Program Design on arXiv. The paper introduces aDSL, an agent-centric domain-specific language for 3D assets, together with a training-free multi-agent loop that plans, writes, executes, checks, and repairs programs. 1

The result matters to the DreamCoder lineage for a precise reason. aDSL makes spatial structure easier for an LLM to express and easier for a verifier to inspect. The paper wraps that representation in a strong repair loop. The reported evidence covers an interface for program generation and correction; learned library growth, wake-sleep learning, and a trained neural recognition model belong to a separate experimental question.

The paper starts from a practical failure in LLM-authored 3D code. An LLM can describe a chair as a seat with four legs, understand that the legs belong below the seat, and still choose coordinates that leave a leg floating or disconnected. Raw Blender or CAD code exposes expressive operations, while the constraints that make an object coherent remain implicit and awkward to check. 1

The aDSL vocabulary moves those constraints into the program. The language is embedded in Python and combines parameterized primitives such as cubes, spheres, and cylinders with union, intersection, difference, translation, rotation, scaling, and affine transformations. Named parent-child attachments give an asset a hierarchy of parts. Kinematic relations can add joints and motion limits to the same structured program. 1

The distinctive layer is spatial reasoning. Each primitive or composed part exposes axis-aligned bounding-box queries for centers, extents, minima, and maxima. Declarative operators then express placement, center alignment, and distribution as relations. The agent can write "place A on top of B" instead of calculating a stack of absolute coordinates. After execution, the same relations can be checked and their arguments can be adjusted during repair. 1

That shared protocol is the joint-design claim. The Planner produces three things: a component decomposition, a set of spatial relations, and a checklist of verifiable requirements. The Coder instantiates those requirements as an aDSL program. The Executor runs the program and renders multi-view evidence. Runtime failures go to a Debugger for targeted patches. Successful executions go to an Image Critic, whose observations are checked against the program by a Code Critic before the Coder receives a revision. 1

The loop gives the critic two kinds of evidence. Renderings expose missing parts, wrong proportions, and visible structural errors. Program state exposes the relations and operations that produced the geometry. The Code Critic uses both to turn a visual complaint into an actionable code change. The paper also keeps user input and the Planner's output in persistent memory while pruning old code, debug logs, and multi-view renderings from transient working context. 1

The main text-to-shape benchmark contains 100 randomly sampled instances: 60 from ShapeNet, 20 from ABO, and 20 from Objaverse. Each instance receives two prompt templates, producing 200 evaluation prompts. The comparison includes code-generation systems, field-generation systems, and a direct mesh generator, so the paper treats the latter two groups as reference points for fidelity rather than as like-for-like training-free competitors. 1

The table below keeps the comparison to aDSL and Scene Language, a code-generation baseline. Each cell reports CLIP, VQA, and execution success in that order.

The reported advantage is consistent across the three datasets: aDSL has higher CLIP and VQA values than Scene Language and keeps a 1.00 execution-success value in every row. The numbers support the paper's narrower mechanism claim. A shared relational representation gives the Planner, Coder, and Critic a common object to produce and check. The text-to-shape numbers cover current-task alignment and execution. Cross-task abstraction survival remains untested.

The image-to-shape comparison supplies a useful boundary. On Toys4K, aDSL reports a CLIP score of 84.42, an FID score of 184.71, and 1.00 execution success. Trellis reports 84.88, 108.20, and 1.00. aDSL is the strongest code-generation method in the paper's comparison, while the field-generation baseline retains better appearance metrics. 1

The ablation on 120 ShapeNet prompts tests whether the gains come from the DSL, the planner, or the repair loop. Full aDSL reaches 29.63 CLIP, 65.34 VQA, 1.00 success, and 4.25 average refinement rounds. Removing spatial utilities changes those figures to 29.38, 63.75, 1.00, and 4.67. Replacing the representation with a raw Blender script gives 28.11, 62.99, 1.00, and 6.08 rounds. Removing the Planner leaves 29.52, 64.12, 1.00, and 5.58 rounds. 1

Disabling refinement produces 29.00 CLIP, 61.53 VQA, and 0.98 success. Removing both spatial utilities and refinement lowers the result to 28.20 CLIP, 59.25 VQA, and 0.97 success. The paired ablation supports the paper's joint-design interpretation: spatial operators expose relations in a form that the critic can check, while iterative refinement gives the agents a way to act on failed checks. 1

The cost of that loop is substantial. A refinement round takes roughly 190 seconds, the system averages 4.7 rounds, and the average total is about 889 seconds per object. More than 95% of runtime comes from LLM responses. In the paper's interaction example, an initial motorcycle takes five rounds and 845 seconds; a follow-up cyber-punk variant reuses the existing context, finishes in one round, and takes 164 seconds. 1

That follow-up result is useful, but its persistence is local. The current program and session context make the next edit cheaper. The experiment stops at session-level reuse. A cross-task test would need to extract a component from one solved object, select it for a new task, and measure whether the component shortens search across independent tasks.

A pairwise user study compares aDSL with Scene Language on 20 cases: 15 text-to-shape and 5 image-to-shape instances. The reported preference is 85.39% for prompt alignment and 86.84% for geometric and visual quality. The study supports the claim that the differences are visible to human raters, while the small case set leaves the broader generalization question open. 1

The paper also demonstrates articulated assets, localized shape editing, high-fidelity generation through an external 3D generator, and scene composition. These applications show that the same structured program can carry geometry, part identity, joints, and scene-level placement. They extend the current program's uses, while cross-task vocabulary growth remains unmeasured. 1

DreamCoder defines the stronger version of the expertise loop. It jointly grows explicit declarative knowledge as a learned DSL and implicit procedural knowledge as a neural recognition model. During wake, the recognizer guides program search. During abstraction sleep, the system extracts common fragments from solved programs into new library primitives. During dreaming sleep, it trains the recognition model on replayed and imagined programs from the learned generative model. 2

LAPS adds language supervision to that setting. Its abstract describes natural-language annotations guiding joint learning of program abstractions and neurally guided search heuristics, with the resulting system improving libraries, search efficiency, and generalization. 3 Stitch addresses another part of the loop: it uses corpus-guided top-down synthesis and pattern matching to extract library functions from a corpus of DSL programs. 4

LILO combines those ideas with LLMs. Its loop uses LLM-guided synthesis, enumerative search, Stitch compression, and AutoDoc-generated names and docstrings. The learned abstractions are then supplied to later search, giving the system a symbolic memory that is both reusable and legible to the synthesizer. 5

The table separates two kinds of reuse that are easy to conflate. aDSL's named components let one asset be assembled hierarchically, and its memory lets a follow-up edit reuse an existing program. DreamCoder, LAPS, Stitch, and LILO treat solved programs as a corpus from which abstractions are learned, compressed, or documented for later independent tasks. The first kind makes one construction easier to manage. The second changes the hypothesis space and the search prior for the next task. 125

The same separation applies to the neural role. aDSL uses LLMs as planners, coders, debuggers, and critics inside a training-free workflow. DreamCoder's recognition model is a learned inference component that predicts useful program components from task data. LILO uses an LLM in synthesis and documentation while still running a symbolic compression step. Prompting, agent orchestration, and execution feedback therefore belong to different parts of the lineage than wake-sleep recognition training. 125

The paper names three limits. Output quality is bounded by the expressiveness of the DSL and its geometric primitives, so complex geometry, materials, and appearance need stronger learned generators. Critic verification relies heavily on 2D renderings, which creates perspective ambiguity. Reliable long-horizon reasoning and repair also depend on strong proprietary LLMs. 1

For DreamCoder-lineage readers, the methodological boundary is sharper. The paper's training-free Plan–Execute–Critic loop tests whether explicit spatial operators make current-task search and repair more reliable. The paper's hierarchical components remain inside the generated asset, and its selective memory preserves the current request, plan, code, and feedback context. The experiments measure current-task repair and session context; cross-task DSL growth, wake-sleep cycles, and a trained neural recognizer learning when to invoke reusable abstractions remain untested. 1

That boundary makes aDSL a useful adjacent development. aDSL turns a hard program-synthesis interface into a relational, executable object that a critic can inspect and repair. The next step would require the language to become an object of learning as well as a tool for generation.

Can aDSL's explicit spatial operators become the substrate of a real library-learning loop, where repeated 3D tasks produce abstractions that measurably shorten search on later objects while a neural recognizer learns when to invoke them?