← Projects
Original series Accepting Agent-Generated 3D Part 2 of 5
  1. Building an Acceptance Harness for Agent-Generated 3D
  2. The 70 mm Gap Our Review Would Have Missed
  3. Checking Material Delivery in Agent-Generated 3D
  4. Checking Motion in Agent-Generated 3D
  5. Evaluating Physics Configuration and Simulated Behavior

The 70 mm Gap Our Review Would Have Missed

An agent's own subframe check caught a rotation-wrap defect in its crank-slider; our planned checks sampled only the authored frames

Watch the video explainer

5:26

Follow one agent-built mechanism through its delivery and a correction between saved poses.

Read the article Watch on YouTube

Loads YouTube when you play.

In this article 5 sections

I asked for a working example of an AI agent taking a written brief for a moving mechanism and returning a scene I could inspect and revise. Along with a finished animation, I wanted the editable model, its working source and a browser viewer. That would let me examine what the agent had built after the demonstration ended.

The resulting mechanism is a crank-slider: a rotating wheel drives a connecting rod, which moves a slider along a straight guide. The dimensions and connections give us specific things to check. This put the delegation idea, giving an agent the production job while I keep the checks, into one concrete assignment. The production steps were left open to Astra, the AI agent used for the build.

The agent delivered the assembly below after finding and correcting a defect in its exported motion. Its own inspection looked between saved frames, where the rod briefly left its pin; our planned review looked only at saved frames and would have missed it. The build gave me both a usable handoff and a reason to change how I review animated scenes.

Watch the recorded orbit insteadHide the recorded orbit
Choose Front, Top, End or Perspective, then press Play. Drag to orbit or use the timeline to inspect a pose. The article controls were adapted after delivery; the model and saved motion are the submitted GLB, the file used by this browser viewer. The editable OpenUSD (USD) scene was exported and checked separately; playing the GLB does not verify that export.

Open the interactive assembly on its own page.

The brief left the production choices open

The task asked for a rotating crank driving a connecting rod and a slider on a straight guide. It specified a 35 mm crank radius, 110 mm rod pin spacing and one full turn every four seconds. Blue structure, metallic linkage, an orange moving component and dark rubber feet made the material choices visible.

The brief required a scene I could revise:

An editable USD scene with named parts, materials, animation, explicit metre scale and timing metadata. Keep the working source file and generator so I can revise it.

The exact brief also required a local viewer, an actual scene render, rebuild instructions and a record of the checks, and it explicitly asked the agent to inspect and correct its work. Geometry beyond the stated dimensions, lighting, modeling method and browser implementation were left to the producer, Astra. No finished 3D asset or prepared scene was supplied.

The producer worked in a fresh workspace, without the earlier articles or the source of Scene Acceptance, my acceptance harness for checking saved 3D scenes against chosen requirements. Python, Blender/OpenUSD, Node and browser automation were installed before it started; it fetched Three.js and the glTF validator itself and chose how to use them. The run record identifies the requested model as gpt-6-astra, with high reasoning effort. The service did not report an immutable backend model snapshot.

My coordinating assistant, the AI assistant that ran this exercise for me, prepared the brief, provisioned the tools and ran the fresh tool-using task under my direction.

The producer took 16 minutes 7 seconds, including its inspections and corrections. Preparing the environment and reviewing the submission took additional work outside that time.

One task included failed exports and corrections

The first USD export had an angle-interpolation problem halfway through the cycle. Blender had exported xformOp:rotateXYZ angles, the crank’s saved rotation values, that wrapped from positive to negative values near 180 degrees. Interpolating between two neighboring frames on either side of that wrap sent the crank the long way around, so a saved pose could look right while an intermediate pose separated the rod from its pin by about 70 mm.

A picture of one saved pose might never show the gap. For this animated explanation, though, the connection is how the wheel’s motion reaches the slider; separating the parts changes what the animation communicates. If I later used that motion to inspect clearance, the wrong path would need correction before relying on the inspection. That additional use was not tested here.

The producer found that during subframe readback, when it reopened the USD and sampled times between saved frames. It changed the USD rotation values to a continuous 0-to-360-degree sequence and reran the check, and its final script sampled 961 frames and subframes. The initial failure and final report are kept in the delivery notes.

There were other corrections. The USD display rate and time-code rate, the number of USD time units per second, were made consistent, and three separately exported animation clips were replaced with one synchronized GLB clip after the viewer’s own check rejected the three-clip export. The coordinator made no edits to the submitted scene, generator or viewer and did not need a second producer attempt.

The angle repair applies to the authored Euler-angle sequence, the per-axis rotation angles saved in the USD. USD uses spherical interpolation for quaternion values, but switching representation would not by itself recover an omitted full turn; the intermediate orientations still have to encode the intended motion.

These retained failures trace the problem to a tool and a representation choice during production. I would diagnose causes like those before calling a defect a hallucination.

What our planned review checked

Before generation, the coordinator fixed nine inspection times, every half second from zero through four seconds, and a 0.5 mm tolerance for the specified relationships. After submission, it froze the files and checked the saved delivery against those requirements. My assistant wrote both the brief and the checks, so this was one exercise checking itself.

The measurement report keeps the samples and tolerance. Every one of those half-second samples landed on a saved frame, where the saved poses looked right, so the review would have missed the defect.

Scroll sideways for more columns.

RequirementObserved resultBoundary
Editable scene and clockUSD opens with metre scale, named parts and a four-second range. Source and generator are present.The coordinator inspected the source handoff; it did not reproduce the entire build in a second clean installation.
Distinct material deliverySeven materials resolve; the four requested surface categories are visibly distinct in the render and viewer.Full USD shader compliance remains incomplete because the checker environment lacked the standard shader definitions.
Specified motionRadius, pin spacing, guide alignment, rod endpoints and phase passed at the nine planned times. Loop endpoint poses match.Nine times only; no whole-path, collision or physics check.
Browser handoffThe delivered GLB loads; orbit, zoom, play/pause and timeline controls work at desktop and mobile sizes without runtime CDN requests.USD and GLB pin positions agree at the sampled times after accounting for their different up axes.

I also ran a selected profile, a chosen set of Scene Acceptance checks, against a copy of the frozen USD. Composition and stage metadata, four material bindings and the four-second duration passed, and the harness report says ACCEPT_FOR_USE for that selection. The verdict covers only that selection: it leaves out the kinematics and browser checks and the unresolved shader-compliance check. The profile used the version 0.4 development timing pack, one of the harness’s reusable groups of checks, and its mapping to the delivered part names was configured after submission.

What the handoff contained

The USD held 107 polygon meshes under named assembly parts, seven bound materials and animated transforms for the crank, rod and slider, at metre scale with Z up and a 0 to 240 time range at 60 time codes per second. It arrived as .usdc and .usda files that the producer checked against each other, with a referenced environment file, the Blender source, the generator, a USD finalizer that keeps the corrected timing and angles, the GLB viewer, a render and diagnostic logs. The text USD shows the authored structure, and the saved-scene readback records what the coordinator found in the binary file. It is editable polygon geometry. It is not a CAD solid model or a physically validated assembly.

The source and delivery bundle includes the editable scene, the local viewer with launch instructions, and the same USD and GLB used for the checks above. The source and recorded evidence are on GitHub.

Astra used Blender 4.5.12 LTS to model, render and export, OpenUSD 25.11 for the readback that exposed the angle problem, Three.js for the viewer and Playwright to exercise its controls. The glTF validator reported zero errors or warnings, and the workflow record keeps the commands and versions.

Because the source includes a specialized generator, I can change a dimension and rebuild. That gives me a usable handoff even if I choose to handle the next request with a script instead of another agent task.

What I still don’t know is whether a task like this costs less than a dedicated mechanism script.

What I would change in the review

The later connection check, now included in Scene Acceptance release 0.5, used the unchanged assembly at 481 times per connection. Its largest gaps, at the crank end and the slider end, were about 0.003005 mm and 0.000955 mm against a 0.5 mm allowance. A separate copy with an injected 1 mm rod offset failed. That offset was an evaluator control, not a defect in Astra’s final submission; the public bundle contains the original delivery.

Later checks and their motion limits

The development package, an unreleased 0.7 snapshot of the harness, now offers static mesh clearance at named times and a continuous attachment check. That continuous check covers translation only, so for this rotating crank the time between samples would still come back unresolved, and the rod ends are checked only at the sampled times.

The same delivery runs through the series’ geometry, materials, motion and physics checks. Mesh interference and manufacturing clearance remain untested, and the physics inspection found no authored rigid-body configuration, so a dynamics task would need more modeling. The tray, panel and block fixtures in those articles are constructed controls, separate from this recorded delivery.

For the next animated delivery, I would check named attachment points between saved poses and include deliberately broken motion to test that review. A pass at those times would still leave continuous attachment to establish.

Disclaimer: The views and opinions expressed in this account are those of my own and do not represent those of my employer, NVIDIA.

← All projects