Into the Omniverse: Developers Use Frontier AI Agents to Turn Ideas Into Physics-Based Simulations

Published · AI Daily — AI-assisted deep research, methodology & disclosure

NVIDIA's Into the Omniverse series shows seven projects in which developers direct frontier AI agents, such as GPT-6 Astra and Claude Fable 5, through natural-language instructions. The agents call Omniverse libraries for GPU-accelerated physics, rendering and sensor simulation. The results include a warehouse humanoid simulator, an autonomous-driving test bed, sensor-validated digital twins, a robot hurdle trial, robotic disassembly in Isaac Sim and a browser-based International Space Station app. Humans set goals and review output. Agents assemble assets, write code and check results in simulation.

On October 8, 2026, NVIDIA published a new entry in its Into the Omniverse blog series. The title is "How Developers Turn Ideas Into Simulations With Frontier AI Agents." The premise is plain. Turning a simulation idea into a working application means assembling assets, connecting physics and rendering, and checking that the scene behaves as intended. Developers now pair frontier AI models with NVIDIA Omniverse libraries so that agents carry much of that assembly and checking work. The division of labor stays the same across the article. Developers direct the agents with natural-language instructions, review the results and guide changes. Omniverse libraries supply GPU-accelerated physics, rendering and sensor simulation. The AI agents wire these pieces together and write animation and application code. The named models include GPT-6 Astra, and in one project Claude Fable 5 agents work alongside Astra. NVIDIA says it will add new examples from its own teams and from developers across the ecosystem. The first project is a humanoid simulator for a warehouse. Frank DeLise, an Omniverse product manager at NVIDIA, used Astra to turn a SimReady warehouse and a humanoid robot into an interactive simulator with first- and third-person views. He directed Astra to connect Omniverse libraries for physics (ovphysx), scene updates (ovstage), rendering (ovrtx) and the user interface (ovui). He also used Astra with SimReady (simready-foundation) to create the physical scene. Astra then generated the animation and application code that tie these capabilities together. The value is practical: before a team automates warehouse tasks, it gets an interactive environment in which to explore task behavior and judge how the work gets done. The second project targets autonomous-driving tests. Doyub Kim, a manager on NVIDIA's simulation technology team, asked Astra to build Zero to Alpamayo, a reusable simulation environment based on San Francisco's Market Street. Kim first had Astra map out the workflow. Then Astra connected asset creation, traffic, Omniverse RTX sensor simulation and Alpamayo driving in stages, and Kim checked each integration. The prototype became a testing ground for comparing models and for tracing how a change in scene or sensor affects downstream driving behavior. A separate Cosmos3-Nano experiment varied weather and lighting in recorded simulation videos, so Kim could compare the driving model's responses to the same scenario under different conditions.

The third project shows most clearly how results get verified. Ashley Reid, who works on RTX sensor validation at NVIDIA, directed Astra and Claude Fable 5 agents to compare ovrtx camera output and raw LiDAR output with recorded data. The agents created two digital twins from scratch and improved two existing ones. Over about three days, Reid guided an iterative workflow: the agents measured differences, created or modified OpenUSD scenes, and checked the results. The changes addressed missing objects, geometry and materials, and acceptance depended on camera and LiDAR metrics. The lesson for developers is to let measured discrepancies drive scene creation and improvement. NVIDIA suggests starting by rendering an OpenUSD scene with the ovrtx minimal Python example, then defining a sensor measure to compare with recorded data. The fourth project is Robo Olympics. Tae Kim, who leads NVIDIA Omniverse engineering and product, used sports videos and natural-language instructions to guide Astra in building an experimental project that tests simulated Unitree G1 humanoids performing sports movements. Under Kim's direction, Astra built controllers and refined them through physics trials. The Newton Physics Engine simulated behavior, the open source NVIDIA Warp framework accelerated calculations, and ovrtx rendered scenes and virtual-camera images. In one experiment the robot cleared a single hurdle in 64 of 100 simulation trials. That result gave Kim feedback for improving the robot's timing and control. Teaching a robot a new movement means checking whether the movement holds up under physical constraints, and simulation makes that check cheap and repeatable.

The fifth project concerns robotic disassembly. Jens Jebens, a senior product manager for OpenUSD at NVIDIA, directed Astra to model a car suspension in PTC Onshape and configure it in NVIDIA Isaac Sim. The agent measured the available space and designed a wrench that the robot could use to reach the suspension's bolts. Jebens reported successful removal of a suspension component in simulation. This links design and tooling decisions to disassembly results and offers a starting point for robot policy training. The sixth project, by Nic Johns, an engineering director at NVIDIA, assembled NASA assets into an OpenUSD model of the International Space Station with telemetry. Johns built the application with a single prompt, then used a follow-up prompt to shift the scene to Earth's daytime side so the planet was visible. The workflow used Blender for asset preparation, and Omniverse libraries for rendering (ovrtx), scene runtime (ovstage) and streaming (ovstream). The article lists a seventh project about turning captured rooms into testing environments, where a digitally reconstructed room needs editable objects. The source text supplied for this report breaks off in the middle of that section, so no details are quoted here. Readers should consult the original NVIDIA post for it. Three patterns run through these cases. First, every project ends in something measurable or checkable: sensor metrics, 64 hurdle clearances in 100 trials, a suspension part removed in simulation. Second, the agents do not deliver in one shot. They work in a loop of measure, modify and re-check, with a human in the loop for direction. Third, all cases rest on the shared base of OpenUSD and the Omniverse libraries, which makes tools and assets easier to join. A sober reading is also needed. The article is NVIDIA's own showcase. It gives no cost figures, no total time comparison and no share of failed attempts, so nobody should infer a general efficiency gain from it.

The implications are still clear. For robotics and autonomous-driving teams, simulation is a core step in training and validation, and building it has long depended on a few engineers who know both graphics and physics. If agents make the glue code cheap, more teams can reach simulation testing earlier. For NVIDIA, having frontier models call Omniverse libraries as tools strengthens the pull of its software ecosystem. The open challenges are narrowing the gap between simulated and real sensors, auditing what an agent changed, and keeping scenes traceable when several people work together. How well the industry answers those questions will decide whether agent-driven simulation moves from demonstration to daily engineering practice.

Sources