What Two Scene Builds Revealed About 3D Acceptance

Once an agent has built a 3D scene, I need a way to turn review findings into a useful next request. A broken material assignment needs a repair. A requirement I forgot to put in the brief needs a decision from me. Sending both back as “the scene failed” leaves the agent to guess what should change.

I followed two agent-built scenes through that process: a dairy layout for visualization and a larger distribution centre with moving parcels, a shuttle and a gate. The Scene Acceptance harness runs selected checks on a saved scene and reports the findings. The agent changes the scene; I still have to decide whether the requirements and evidence are enough for its intended use.

The dairy showed the straightforward case: a validator found broken material bindings and the producing agent repaired them. The distribution centre exposed two different problems. Its automated rejection came from a delivery policy the brief never stated, while separate review found a route indicator showing the wrong state between events that passed their checks. Following the feedback through to a repaired delivery helped me distinguish a better brief from a better scene.

Two briefs, with different demands

The issued dairy brief describes a conceptual 24 × 16 m hall for milk reception, separation, treatment, storage and cleaning. I chose realistic visualization as its purpose, and an assistant helped specify the equipment and acceptance questions. Its 5,000 litres/hour capacity is illustrative, not a validated dairy design.

For the second assignment, I wanted a larger scene with motion and explicit texture requirements. A prim is any scene element, visible or not. The second brief asks for a fictional 120 × 96 m distribution centre with six docks, 3,840 rack positions and more than 100,000 useful composed prims. Its 30-second sequence gives three parcels named scan and destination times and routes them past diverters to outbound lanes or a reject lane. It also stops one of them from 12 to 15 seconds, carries an attached pallet on a shuttle, swings a gate and switches lamps amber → red → green. Two supplied PNGs must keep their pixels, size and orientation. The animation is kinematic; contact simulation is outside the brief.

The dairy: a concrete defect with a local repair

The dairy producer used harness release 0.5.0 during its build. At the first detailed revision, NVIDIA’s UsdDanglingMaterialBinding validator rule returned failures for a flow-meter display and two HMI (human-machine interface) screens; their assigned material paths did not exist.

The agent registered the display textures in its generator, regenerated the scene and reran the checks; the binding rule passed and the baseline of general checks returned ACCEPT_FOR_USE for its selected scope. The failing USD was not preserved, so the report and repair log are what survives of that revision. The visual requirements and the agent’s proposed tolerances stayed open.

The producer also planted fourteen faults in copies of the finished scene: general checks rejected two, and adding task-specific measurements raised the total to seven. The other seven were not rejected by the selected scripts and remained under review; a blocked aisle was among them. I would use controls like that to find gaps in the checks, and keep them apart from failures in the delivery.

The larger trial: preserve the delivery before evaluating it

For the distribution centre, the producer received only the neutral assignment packet in a fresh project. The coordinator who wrote the brief prepared the checks before the first delivery arrived. That package (V0) was archived before any findings went back, and the evaluation scope stayed unchanged through the repair.

The released harness stopped at 10,000 prims, so the trial used a 0.5.1 development build that took caller-selected limits and reported insufficient evidence above them. Its brief-derived checks ran from a trial-owned check pack, a group of checks written for this trial. A synthetic 150,000-prim control still found a dangling binding placed on its last mesh, a test that large inputs were not being truncated. The trial records give the code version, controls and limits.

V0 returned 51 PASS and one FAIL across 52 rows. All 24 brief-derived scripted checks passed, including parcel event timing, the stop, attachment, gate/lamp schedules, reference textures and selected material values. The other 28 rows were general checks, among them the OpenUSD and NVIDIA Asset Validator rules. The failing row was NVIDIA’s NormalsExistChecker: all 121,602 mesh subjects lacked authored normals under the selected polygon-delivery policy.

The brief had not asked for authored normals. It was one policy applied to 121,602 meshes. Missing normals did not by themselves show that the scene was invalid for this visualization task. I needed to decide whether the receiving application required them. The downstream normal-validity checks had skipped those subjects, so their aggregate PASS offered no evidence about normals either.

A parcel can arrive on time while its route indicator is wrong

In this scene, diverters at the sorting junctions act as route indicators, showing which branch each passing parcel takes: an outbound lane such as D01, or the reject lane. Parcel P02 reached reject lane R01 at 19.999 seconds, within the requested tolerance. But while it passed the first junction from about 14.755 to 15.791 seconds, DIV01, the diverter there, still showed the branch for P01, a parcel bound for D01. The endpoint and timing checks passed; they did not test that indicator’s meaning through every traversal.

A separate geometry-review agent found the mismatch. The producer had described the raised vanes as non-contact indicators, so the repair only had to make the displayed route agree with the parcel’s path.

That simplification fits an explanation of parcel flow: the indicator shows the route without physically pushing the parcel. Its direction still matters, because a viewer following it would otherwise be shown a different route from the parcel’s actual path. A study of physical diversion would need a suitable contact model and additional evidence. Declaring the non-contact choice let me judge it against this scene’s purpose.

Before: the vane remains selected toward D01.

After: the arrow indicates straight for P02.

The indicator and the normals failure went back to the producer in the same redacted feedback. It contained eight items, grouped below by the repair they requested, with the automated condition kept apart from review concerns. The producer’s response records how it addressed each one.

The original producer returned a complete repaired package, V1. The unchanged scripted scope passed 52/52 rows, with no regression among the 51 previously passing rows. Evaluation took about 75 seconds and 1.71 GB peak process memory on the recorded host.

Read the sequence description and measured events for a text alternative to the video.

What I would carry into the next assignment

Write the delivery policy into the brief. The dairy bindings were broken whatever the brief said; the normals failure only happened because nobody had told the builder about the rule. Keeping those two apart in the report gives the builder a repair request it can understand, and it gives me a better next brief, because an unstated rule left out again would come back as the same failure on the next delivery.

Check the operation between named events. None of the 24 scripted requirements tested what the indicator meant during each traversal, and DIV01 was wrong for about a second between two timed events that both passed. The gate, the payload attachment and the stop interval gave the scripts useful intermediate requirements. For the diverter’s meaning I would name a review step in the brief; here it took a review agent working outside the harness’s optional judge path (its model-based review of supplied views). The brief already required the diverter to hold the correct route until the parcel cleared. The repair addressed a missed requirement; the review exposed a gap in the selected checks.

Make the repair observable. The missing dairy snapshot limits replay. For the distribution centre, the first package, the exact feedback, the producer’s response and the revised package all survive. The same contract, the file of targets and tolerances the checks read, can be rerun, and matched views show what changed. That record is more useful to me than asking the builder whether it fixed everything. The evidence collection and the published evidence subset support the findings; the trial’s runtime, custom pack and full deliveries are not in the public repository, so neither replays a whole build.

Keep usability in the acceptance decision. Passing every scripted row still left a serious usability concern. The producer recorded about 4.5 viewport draw callbacks per second while orbiting the scene imported into Blender, in solid view, and 2.63 per second over a short playback sample of frames 0–47. Those numbers were checked against the producer’s logs but not rerun. The brief set no minimum frame rate. For a scene someone has to navigate, I would state the target application, machine and required performance.

The validators supplied structural findings; the harness kept the selected checks and measurements together, while the caller supplied review and repair coordination. From two builds I can’t tell whether running the harness this way beat a validator plus a careful reviewer. The coordinator had seen some draft code, so the test was not blinded. The builds used different agents and tools. Physical operation and final owner acceptance remain unverified; the coverage record names the packs, subjects and limits.

These different repairs led me to a framework for deciding what needs to change and who should act. I would start the next assignment by agreeing the delivery policy and the evidence needed to judge the operation.

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