Source-linked AI summary
MARC: Mechanism-Aware Reflective Correction for Articulated Object Code Generation
Xiong Yang, Junkun Hao, Zijian Xiao, Zipeng Ye, Yuchen Xie, Ran Yi
TL;DR
Generating articulated objects that execute intended motion is challenging when connections form closed loops or joint motions are coupled. MARC shares an executable kinematic graph across construction, solving, and correction, using solver diagnostics to guide probes and revisions. On a 20-object evaluation, it achieves 67.8% valid motion coverage and 60.0% overall success with Kimi-K3.
Problem
Generating articulated objects requires coordinating geometry and connections so the complete mechanism executes requested motion, a challenge heightened by closed loops and coupled joints.
Source: §1 · p. 2Method
MARC shares an executable kinematic graph across program construction, motion solving, and graph-guided correction of articulated-object programs.
Source: §1 · p. 2Results
67.8% valid motion coverage and 60.0% overall success on 20 articulated objects with Kimi-K3.
Source: §1 · p. 2Takeaways & Limitations
Ablations indicate the value of graph-based mechanism support and using connection and constraint information during correction.
Source: §4.3 · p. 8MARC achieves 100% structural correctness and 98.2% coupled-motion correctness, but valid motion coverage is 67.8% and overall success is 60.0%; closure errors and interference remain limitations.
Source: §4.2 · p. 7
Abstract
from arXiv · showhide
Generating an articulated object from images and text requires more than plausible parts and movable joints: the assembled mechanism must execute the intended motion. This is particularly challenging for closed-chain and coupled mechanisms, where an error in one connection can block motion or separate connected parts. We introduce MARC, Mechanism-Aware Reflective Correction, which shares an executable kinematic graph across program construction, motion solving, and correction. The graph binds physical connections to local attachment frames and represents loop closures and joint-coordinate couplings. Given prescribed driver inputs, a numerical solver computes follower motion and associates errors with specific connections and configurations. The agent uses these diagnostics to probe possible causes, revise connections or geometry, and retest the mechanism along the original motion paths. On a 20-object test set, MARC with Kimi-K3 achieves 67.8% valid motion coverage and 60.0% overall success, outperforming six baselines. Starting from the same initial candidates, correction improves these scores by 13.7 and 20.0 percentage points, respectively. Ablations further show the benefits of graph-based mechanism support and graph-guided repair. Project homepage: https://demianmusk.github.io/MARC-Home/.
1 INTRODUCTION
MARC addresses the challenge of generating articulated objects whose connected parts execute the requested motion, especially in closed-chain and coupled mechanisms. It shares an executable kinematic graph across construction, solving, and correction, and improves motion-related benchmark outcomes on 20 objects.
1 INTRODUCTION
- Generating a static match is insufficient: closed loops and coupled joints make it challenging to coordinate geometry and connections so the complete mechanism realizes requested motion.A single driving input may need to move several connected links while keeping their hinges intact.Source: §1 · p. 2
- For closed-chain and coupled structures, an observed failure may have several causes, so effective repair must account for interdependent connections and the effects of an edit on the assembly.A blocked follower may reflect misplaced attachments, restrictive joint limits, or part interference.Source: §1 · p. 2
- MARC shares an executable kinematic graph across construction, motion solving, and correction to generate articulated-object programs from images and text.The graph represents rigid bodies, physical connections, loop closures, and coordinate couplings; numerical tools solve follower motion and associate errors with relevant mechanism entities.Source: §1 · p. 2
- 67.8% valid motion coverage and 60.0% overall success; correction raises these from 54.1% and 40.0% on the same initial candidates.Structural and coupled-motion correctness remain unchanged, identifying motion validity as correction’s main benefit in this comparison.Source: §1 · p. 2
2 RELATED WORK
Prior work includes learned articulated-asset generation, agentic 3D code generation, and computational mechanism design. MARC connects mechanism topology and constraints to geometric attachment locations and uses execution diagnostics to guide correction.
2 RELATED WORK
- Learning-based methods generate part geometry and articulation structure, while agentic systems author assets as editable code with method-specific checks and iterative feedback.The passage names graph-and-diffusion approaches, image-based methods, and code-generating agents, including Articraft, Procedura, and aDSL.Source: §2 · pp. 2–3
- MARC grounds each physical edge of its kinematic graph in a body-local attachment frame, while topology, interface parameters, and coordinate couplings participate together in solving and correction.This applies to generation from images and text, with the agent constructing the initial mechanism and numerical execution localizing issues for correction.Source: §2 · p. 3
- Computational mechanism-design systems optimize connectivity or continuous parameters for target motion; MARC instead applies attachment-aware kinematics to image-and-text generation and subsequent program correction.The related work includes LinkEdit and Kinematic Kitbashing, whose attachment-geometry treatment during motion is identified as an important reference.Source: §2 · p. 3
3 METHOD
MARC generates articulated-object programs against a target motion domain using an executable kinematic graph shared by its authoring interface, numerical solver, and correction workflow. Socket-bound connections and graph-associated diagnostics support solving and targeted repair.
3 METHOD
- MARC takes reference images, a text description, and target motion domain U, then generates a program whose articulated object matches required appearance, connections, and motion.A prescribed driver input fixes joint coordinates while the solver determines follower coordinates; the four-cylinder example drives crankshaft angle to compute piston and connecting-rod motion.Source: §3 · p. 3
3.1 AN EXECUTABLE KINEMATIC GRAPH FOR MECHANISM AUTHORING
- The mechanism-authoring interface represents rigid bodies, socket-bound physical connections, loop closures, and joint-coordinate couplings in an executable kinematic graph.The SDK exposes the interface to the agent, supporting closed chains and coordinated edits to attachments and geometry.Source: §3.1 · pp. 3–4
- Each physical connection binds two body-local sockets and a connection type, which locates the connection in geometry and specifies permitted relative motion.The screw–nut connection also couples relative rotation to axial displacement according to screw lead.Source: §3.1 · p. 4
- Shared construction parameters let a linkage-layer spacing edit update body positions, socket depths, and pin lengths together while preserving connections and improving clearance.The agent can revise geometric clearance and associated attachments as a coordinated edit.Source: §3.1 · p. 4
3.2 MOTION SOLVING AND DIAGNOSTICS FROM THE KINEMATIC GRAPH
- For each prescribed driver input, Solver fixes driver coordinates and minimizes constraint residuals over follower coordinates within their joint limits.Solved configurations initialize subsequent samples to continue along the same motion branch.Source: §3.2 · pp. 4–5
- At sampled configurations, Solver checks constraint tolerances, joint limits, continuity, and prohibited interference; diagnostics identify implicated bodies, joints, or sockets and their configurations.The initial solve also seeks a configuration satisfying declared connections and explicit coordinate couplings.Source: §3.2 · pp. 4–5
3.3 GRAPH-GUIDED EVALUATION AND REFLECTIVE CORRECTION
- MARC uses the graph, constraints, socket frames, and Solver diagnostics to locate motion issues, investigate causes, and choose revisions to connections or parameters.Judge selects probes at reported failure configurations and plans repairs that preserve required connections and coordinate couplings.Source: §3.3 · pp. 5–6
- After edits, Solver reconstructs constraints and retests the complete mechanism along the original motion paths; Evaluate checks results against reference requirements.Reviewer checks that required changes were made and connections and coordinate couplings were preserved; unresolved issues can guide further rounds within a preset limit.Source: §3.3 · p. 6
4 EXPERIMENTS
MARC is evaluated on complex articulated mechanisms using structural, motion, and geometric measures. Its strongest reported comparison is higher valid motion coverage than Articraft; harness and ablation comparisons examine the contribution of the full workflow and graph-based support.
4.1 EXPERIMENTAL SETUP
- The evaluation covers 20 complex articulated objects and six baselines, with measures for executability, structure, valid motion, coupled motion, overall success, and geometric agreement.Motion metrics assess prescribed paths and follower behavior; geometric agreement compares generated objects with manually constructed reference models.Source: §4.1 · p. 6
4.2 COMPARISON WITH EXISTING METHODS
- 67.8% valid motion coverage for MARC versus 0% for Articraft, with both methods at 100% executability.The first four baselines satisfy few critical part-role and connection requirements, and none completes the prescribed mechanism tasks.Source: §4.2 · p. 7, Table 1 · p. 7
- 100% structural correctness and 98.2% coupled-motion correctness coexist with 67.8% valid motion coverage and 60.0% overall success for MARC.The folding desk encounters interference before completing its travel, and the excavator fails the bucket-closure check.Source: §4.2 · p. 7
- MARC improves all six aggregate geometric-agreement metrics, while Articraft has higher static gIoU and mIoU on the gear train despite an incorrect transmission relationship.The mechanism and geometric metrics capture these aspects separately.Source: §4.2 · p. 7, Table 2 · p. 7
4.3 ABLATION ANALYSIS
- With Kimi-K3, Direct API achieves 0% valid motion coverage and overall success versus 67.8% and 60.0% for full MARC; with GPT-6 Astra, full MARC succeeds on all 19 tested objects versus 31.6% for Direct API.Within each backbone, configurations use the same objects; the comparison measures the full harness rather than any single component.Source: §4.3 · p. 7, Table 3 · p. 8
- Reflection raises valid motion coverage from 54.1% to 67.8% and overall success from 40.0% to 60.0%, while structural and coupled-motion correctness remain unchanged.Removing graph-based mechanism support reduces coupled-motion correctness from 98.2% to 45.8% and valid motion coverage to 34.4%; graph-guided repair also lowers all four reported metrics.Source: §4.3 · p. 8, Table 4 · p. 9
5 CONCLUSION
MARC shares a kinematic graph across geometry, physical relationships, motion solving, and agent-guided correction. On the Kimi-K3 evaluation, correction primarily improves valid motion and overall success.
5 CONCLUSION
- MARC’s shared kinematic graph connects geometry and physical relationships to numerical motion solving and agent-guided correction.Diagnostics associated with mechanism entities guide probes and edits to connections and geometry.Source: §5 · p. 9
- On the 20-object Kimi-K3 evaluation, correction raises valid motion coverage from 54.1% to 67.8% and overall success from 40.0% to 60.0%.Correction primarily improves valid motion.Source: §5 · p. 9
- Adaptive probe selection and reuse of numerical results are identified as promising directions for reducing correction’s computational cost.Source: §5 · p. 9
A IMPLEMENTATION DETAILS
MARC’s implementation uses a shared executable kinematic graph to connect geometry, physical connections, and motion constraints. A numerical solver assembles mechanisms and checks follower motion along prescribed paths.
A.1 PROGRAMMING ENVIRONMENT AND WORKFLOW
- The Python implementation extends Articraft’s authoring interface with mechanism construction and diagnostics, using CadQuery for geometry and NumPy and SciPy for numerical computation.Generated programs declare geometry, rigid-body membership, attachment frames, joints, loop-closing connections, and coordinate couplings.Source: §A.1 · p. 12
A.2 KINEMATIC GRAPH AND GEOMETRY INTERFACES
- The graph represents rigid bodies, a joint tree, and additional physical connections that close mechanism loops.Connections bind body-local sockets and specify connection types; explicit coordinate couplings and physical connection constraints form the constraint set.Source: §A.2 · p. 12
- Figure 5 compares direct API generation with the full MARC harness using the same reference inputs within each backbone.The comparison evaluates the combined harness, including tool calls, execution feedback, and reflective correction, rather than isolating one component.Source: Figure 5 · p. 13
- The SDK offers composable interfaces for common mechanisms and coordinates geometry and attachment edits through shared construction parameters.Its guidance and examples explain how to declare geometry, local attachment frames, and motion constraints together.Source: §A.2 · p. 14
A.3 ASSEMBLY AND FOLLOWER-MOTION SOLVING
- For prescribed driver inputs, Solver assembles the declared mechanism and solves bounded follower coordinates, checking motion along sampled paths.Checks include attachment errors, joint limits, branch continuity, and geometric interference; adaptive refinement adds samples when motion changes sharply or residuals rise.Source: §A.3 · pp. 14–15
A.4 GRAPH-ASSOCIATED EVIDENCE AND LAYERED EVALUATION
MARC associates solver findings with mechanism entities and uses layered evaluation to guide probes and repairs. Revised candidates are re-solved along the original paths, with changes and evidence tracked across versions.
A.4 GRAPH-ASSOCIATED EVIDENCE AND LAYERED EVALUATION
- Solver findings identify the program state, driver input, implicated body, joint, or socket, tested configuration, and relevant measurement.Examples include loop-closure residuals, active joint limits, and interference; program versions and model hashes tie evidence to the executed candidate.Source: §A.4 · p. 15
- Evaluate combines reference inputs, graph and constraint information, renderings, and numerical diagnostics to check structure, motion, and geometry.Its three levels assess topology and transmission relationships; motion, loop preservation, limits, continuity, and interference; and part shapes and dimensions.Source: §A.4 · p. 15
A.5 STRUCTURED REFLECTION AND COORDINATED REPAIR
- Judge probes implicated connections, constraints, and geometry, then uses probe results and reference requirements to inform repair decisions.A probe may temporarily modify a joint limit to test whether it restricts closure when a follower reaches that limit.Source: §A.5 · p. 15
- Repair plans specify targets, diagnosis, permitted scope, dependencies, relationships to preserve, expected effects, and rechecking requirements.Interdependent changes can require coordinated edits, such as adjusting body positions, socket depths, and pin lengths when changing linkage-layer clearance.Source: §A.5 · p. 15
- After review, each candidate returns to Solver for testing along the original paths, and Evaluate compares results with reference requirements.Local improvements and regressions inform further decisions; correction may repeat within the remaining budget.Source: §A.5 · p. 16
- When assembly absorbs a rest offset into a joint origin, the corresponding limits are transformed by the same offset.This distinguishes a coordinate-zero change from a change in the mechanism’s physical motion range.Source: §A.5 · p. 16
A.6 EXECUTION CONTROL AND RESULT RECORDING
- The workflow repeats generation, solving, evaluation, and reflective correction for at most Bcorr rounds, retaining program versions and associated execution evidence.Reported metrics come from the independent evaluation procedure, not internal Evaluate judgments.Source: §A.6 · p. 16
A.7 IMPLEMENTATION OF THE NO-GRAPH ABLATION
The no-graph ablation regenerates programs from task inputs and uses direct-motion execution in place of MARC’s graph-based mechanism support. Its comparison therefore measures a bundle of removed capabilities, not graph notation alone.
A.7 IMPLEMENTATION OF THE NO-GRAPH ABLATION
- The no-graph configuration removes graph-based construction and execution support, including loop-closure declarations, the graph-based Solver, and mechanism-authoring interfaces.This is a joint ablation of the representation and its associated execution and authoring support.Source: §A.7 · p. 16
- It regenerates programs from task inputs, using general-purpose geometry and numerical libraries to implement driver-to-pose motion directly.The program exposes build() for body geometry and appearance and motion(controls) for world-space transformations; geometry remains fixed during motion.Source: §A.7 · p. 16
- The configuration retains execution, rendering, and geometric-contact checks, and allows free-form execution-conditioned repair without graph-based localization or planning interfaces.The comparison uses an independent evaluation protocol and does not isolate graph notation alone.Source: §A.7 · pp. 16–17
B REPRODUCIBILITY DETAILS
The reproducibility procedure links object inputs, candidate versions, configurations, and scores, and distinguishes replaying saved artifacts from rerunning generation. Reference models define the structural and motion requirements used for evaluation.
B.1 REPRODUCTION UNITS AND VERSION CORRESPONDENCE
- Each object-level reproduction record associates reference inputs, run configurations, program versions, and results, with hashes distinguishing candidate versions.Correction starts from its specified initial candidate, whereas regeneration starts from reference inputs; the routes are recorded separately.Source: §B.1 · p. 17
B.2 ENVIRONMENT AND MODEL CONFIGURATION
- Reproduction restores the software and numerical configuration for the target experiment; Kimi-K3 uses the high reasoning setting.Regenerating candidates requires access to the corresponding model service, while numerical replay and external scoring of saved artifacts do not require new model calls.Source: §B.2 · p. 17
B.3 TWO REPRODUCTION ROUTES
- Replay loads and tests a saved program with its native connections, loops, couplings, limits, and driver paths, then recomputes metrics from object-level results.Rerunning instead starts Topology from reference inputs and repeats solving, evaluation, and budgeted correction before independent scoring.Source: §B.3 · pp. 17–18
B.4 STARTING POINTS FOR COMPARISONS AND ABLATIONS
- Ablation comparisons retain their specified initial candidates, while baselines use native outputs and adapters that do not add connections or modify geometry.The no-graph configuration regenerates from reference inputs and uses direct-motion execution without graph-based Solver support or SDK guidance.Source: §B.4 · p. 18
B.5 VERIFICATION AND AGGREGATION
- Verification checks object and program versions, driver inputs, sampling, execution, and object-level scores; aggregate metrics are recomputed from those results.Unreachable prescribed samples count toward failures under the evaluation protocol, while retries retain separate identifiers and provenance.Source: §B.5 · p. 18
C.1 MANUALLY CONSTRUCTED REFERENCE GROUND TRUTH
- Reference models for 20 articulated objects are manually constructed and annotated against input images, covering geometry, rigid-body decomposition, connections, and motion relationships.Ground truth includes geometric models and functional requirements for assessing structural and motion correctness.Source: §C.1 · p. 18
- Reference requirements specify part roles and connections, driver paths and follower behavior, and which connections must remain intact during motion.When images do not uniquely determine details, evaluation is restricted to reliably judged requirements and permits functionally equivalent alternatives.Source: §C.1 · p. 18
C.2 EVALUATION UNITS AND COMMON CONVENTIONS
The evaluation uses configuration-specific object sets and prescribed motion paths, with separate measures for executability, structure, motion, and geometry. It also specifies object-level aggregation, failure handling, and confidence intervals.
C.2 EVALUATION UNITS AND COMMON CONVENTIONS
- Within each backbone, direct API and full-harness configurations use the same object set; motion tests follow prescribed paths from prescribed starts.Forward and reverse motion are assessed on their respective paths, and sampled domains are not shortened to fit a generated model.Source: §C.2 · pp. 18–19
C.3.1 EXECUTABLE RATE (ER); C.3.2 STRUCTURAL CORRECTNESS (SC)
- ER checks loadability and motion-control access, while SC assesses annotated part roles and connection requirements.Structural requirements include required parts, connected-body identities, joint types, attachment locations, and loop closures.Source: §C.3.1 · p. 19, §C.3.2 · p. 19
C.3.3 VALID MOTION COVERAGE (VMC); C.3.4 COUPLED-MOTION CORRECTNESS (CMC)
- VMC counts prescribed samples reached along valid paths; CMC checks follower responses, so correct local responses alone do not establish complete-path validity.VMC requires applicable connection, loop-closure, joint-limit, and collision conditions; CMC assesses participation, direction, phase, transmission, and travel.Source: §C.3.3 · p. 19, §C.3.4 · p. 20
C.3.5 OVERALL SUCCESS RATE (OSR)
- OSR is a binary object-level decision requiring executability, critical structural and motion correctness, complete valid sampled coverage, and a functionally consistent layout.It is not an average of the other metrics; internal Solver termination alone does not establish success.Source: §C.3.5 · p. 20
C.4.1 CORRESPONDENCE, ALIGNMENT, AND NORMALIZATION; C.4.2 PART BOUNDING-BOX AGREEMENT: MIOU AND GIOU; C.4.3 SURFACE DISTANCES: PC AND OC; C.4.4 STATIC AND DYNAMIC COMPARISONS
- Geometric comparisons use fixed functional-part correspondences and one global alignment; 3D bounding-box and surface metrics measure spatial agreement separately from mechanism correctness.PC emphasizes corresponding parts, while OC compares complete object surfaces; missing reference parts receive a penalty.Source: §C.4.1 · pp. 20–21, §C.4.2 · p. 21, §C.4.3 · p. 21
C.5.1 AGGREGATION AND FAILURE HANDLING
- Primary metrics are aggregated at the object level, and generation failures or non-executable results remain failures rather than being removed from scoring.CMC retains failed objects in its denominator when they have coupled-motion requirements.Source: §C.5.1 · p. 22
C.5.2 95% CONFIDENCE INTERVALS
- Confidence intervals use object-level analyses: Wilson intervals for ER and OSR, and conservative mean intervals for SC, VMC, and CMC.The intervals assume independent objects from a comparable population and do not quantify repeated-generation variability, annotation error, or simultaneous coverage.Source: §C.5.2 · p. 22
C.5.3 CONFIDENCE INTERVAL RESULTS
The section reports two-sided 95% confidence intervals for the five primary metrics as percentage endpoints. The table gives interval endpoints rather than means or standard deviations.
C.5.3 CONFIDENCE INTERVAL RESULTS
- Table 10 reports object-level two-sided 95% confidence intervals for all five primary metrics.Its entries are interval endpoints, not means or standard deviations.Source: §C.5.3 · p. 22, Table 10 · p. 23
- Table 10 expresses all confidence-interval endpoints as percentages.The corresponding mean scores appear in the main text.Source: §C.5.3 · p. 22, Table 10 · p. 23
- Both GPT-6 Astra configurations use 19 objects, while all other configurations use 20; excluding the dishwasher, CMC denominators are 18 and 19, respectively.Source: §C.5.3 · p. 23
C.6 ABLATION 1: BACKBONE MODEL AND HARNESS COMPARISON
Ablation 1 compares direct API generation with the complete MARC harness for each backbone using the same reference inputs, object set, and evaluation criteria. The comparison measures the full harness rather than isolating individual components.
C.6 ABLATION 1: BACKBONE MODEL AND HARNESS COMPARISON
- Direct API and full-harness configurations independently generate outputs from the same reference inputs and use the same object set and evaluation criteria within each backbone.The full-harness configuration runs the complete workflow, while direct API omits staged diagnostics and reflective correction.Source: §C.6 · p. 23
- The comparison measures the system-level effect of the full harness and does not attribute differences to any single component.Cross-backbone comparisons should distinguish each backbone’s complete evaluation set from their common subset.Source: §C.6 · p. 23
- Figure 5 provides a qualitative comparison of generated results; structural and motion judgments follow the appendix evaluation protocol.Source: §C.6 · p. 23