A while back I was in a meeting with a partner who already ships a digital-twin product. Their application renders with glTF, the kind of light, widely supported 3D format a lot of visualization tools run on, and for what they do it does the job. They were weighing whether to extend onto Omniverse, and the way they framed it stuck with me: Omniverse looked like a more accurate renderer that came with a heavy compute bill. A plant operator reading a scene for context did not need that realism.
On the rendering question, they were right. If the job is to put a useful 3D view beside an alarm or a KPI, a lighter viewer may be the better choice. I would not bring in Omniverse just to make the same picture more realistic.
What bothered me was that we were evaluating only the last step, the image on the screen. The harder industrial problem starts earlier. It is getting the plant layout, equipment identity, engineering geometry, operating data and simulation behavior to refer to the same physical world while each team keeps working in the tools it already uses.
I used to answer this by drawing Omniverse as a six-layer stack and pointing out that the renderer occupied one box. That description was not completely wrong, but it was a weak answer. It asked someone to remember the anatomy of a product instead of showing why an industrial project might need it, and I had been making the same mistake from the other direction by still starting with Omniverse rather than with the plant.
Omniverse gets treated as a rendering tool because the render is what survives in a screenshot. In an industrial system, though, its more useful role is as the place where different descriptions of the facility can be brought together, inspected and used.
I am looking at this through manufacturing because I have spent more than twenty-two years around manufacturing and industrial systems. Similar needs may show up in media and entertainment, architecture and other fields where many tools and contributors share a world, but I have not worked deeply enough in those workflows to argue from them. I am sticking to the industrial case I know.
One machine, many disconnected descriptions
The plants and MES programs I know already have a lot of structure. A PLC and SCADA system know a machine through tags and signals. OPC UA and its Companion Specifications can give machines and their data domain-specific information models. MES knows the operation, material, order and genealogy. ERP and maintenance systems know cost, inventory and work history.
Engineering sees the same facility differently. The pump that has a control-system tag may be a symbol in a P&ID, a solid in a CAD assembly, an item in a bill of materials and a shape in a laser scan. A robot team may have another version with joints, collision geometry and grasp points. Each representation can be correct for its own job and still fail to connect cleanly to the others.
I do not think the answer is one giant “single source of truth.” I would not move high-rate telemetry, maintenance records, CAD source files and every drawing into one database. Those systems should remain authoritative for the data they own. What is missing is a shared address for the physical thing, so that the geometry, live state, engineering record and simulation behavior can resolve to the same asset and the same place.
Industrial teams have spent years standardizing data exchange inside individual layers. The gap is often between the layers: the machine model does not automatically know which object in the 3D scene represents it; the CAD object may not know which live tag or work order belongs to it; and the 2D drawing may use an identifier that changed two integrations ago.
OpenUSD gives the work a shared address
OpenUSD is useful here because it is more than a geometry file. It describes a scene as named objects with properties and relationships, and it can compose many independently owned layers into one resolved stage. References let an asset remain separate while it appears in a larger plant. Overrides let a project add context without rewriting the source. Variants can preserve different configurations of a line or cell.
The mechanical team can keep ownership of the equipment geometry. The facility team can own the building and layout. A robotics team can add collision geometry and reach envelopes. Operations can map live state onto the same equipment identities. A safety review can add zones and annotations in another layer. They do not all have to work in one application or overwrite one master file for the combined scene to exist.
OpenUSD does not already contain a universal industrial semantic model, and it does not infer that Pump_17 in a CAD export is the same physical asset as P-101 in the historian. Teams still have to define identity, units, coordinate frames, ownership and update rules. The Alliance for OpenUSD’s Industrial and Engineering Digital Twin interest group is still working on requirements for this area.
I think of OpenUSD as the shared spatial context. It does not replace MES, PLM, the historian or the control system; it gives their data a common place in the modeled facility.
What the platform has to do
When several teams have to keep using the same twin, the platform has to do more than store the scene. It has to bring in 2D, 3D and operational sources; preserve source ownership and versions; map them into common coordinates and equipment identities; let teams review and change their own parts; expose the result through applications and services; and run physics, sensor and what-if workloads against it. If every new use case rebuilds that path, the twin will not scale.
I would often start with visibility. Put equipment state, alarms and KPIs into a recognizable plant context and people can see what is happening without translating a tag name in their head. That can be a worthwhile first release. But if the model stops there, the project has built a spatial dashboard. The same context becomes much more useful when an engineering team can test a layout change, an operations team can compare schedules, or a robotics team can simulate and train against the facility without constructing another model from scratch.
OpenUSD by itself does not provide enterprise storage, synchronize a live project, run physics or give a plant team an application. Omniverse adds the surrounding pieces: data exchange and storage, access and collaboration services, an application framework, and libraries for rendering, physics and simulation. NVIDIA’s current Omniverse developer catalog exposes these as components that software teams can use separately rather than as one monolithic application.
A project can start with visibility and reuse the same OpenUSD work later for simulation, optimization or Physical AI instead of rebuilding it, although many projects will never need every part.
When I say collaboration, I mean different tools contributing to the same evolving context. Several people looking at one viewport is only the visible part. Omniverse Nucleus, for example, is documented as a database and collaboration engine that lets applications, users and services share and modify OpenUSD-based worlds. One person may be reviewing a scene in an interactive application while a connector publishes an engineering change and a service processes the updated asset in the background.
A common 3D view lets a controls engineer, a simulation engineer and an operator see whether they are talking about the same pump, cell or safety zone. It makes conflicts visible. The scene is one use of the model. The same model can support a layout review, a robot-fleet simulation, synthetic sensor generation, a training environment, or an operational view tied to live state.
The same composed scene can also carry geometry, joints, materials, collision shapes and sensor definitions into a physics run. A proposed line change can be tested before equipment moves. A robot policy can train against the cell it will later enter. A camera layout can be checked against the occlusion and lighting conditions of the facility. I look at the render to understand what happened in the run, but the modeled behavior is what supports the decision.
Industrial and Physical AI applications need a shared foundation
I see the platform more clearly when I put several use cases on the same plant. Operational visibility, design review, line optimization, virtual commissioning, synthetic-data generation, robot training, fleet simulation and an agent helping an operator diagnose a fault may all become separate applications. They still need the same basic answers: what the assets are, where they are, how they relate, which coordinate frame is in use, what a safe zone means and what is happening now. If every use case builds those answers again, the plant ends up maintaining incompatible twins.
The shared layer has to do more than hold a 3D model. It has to compose meaning and content from different sources, let teams collaborate while keeping ownership and versions clear, perform with large scenes and changing state, support physical fidelity where a use case needs it, and accept new data types, schemas, tools and simulation functions as the system grows. A robot policy or an operator workflow can still be specific to its task. It should not need its own private definition of the factory around it.
I think Omniverse is focused on this shared layer. OpenUSD provides the composable context. Omniverse adds libraries and services around exchange, storage and synchronization, shared runtime state, rendering, physics, sensor simulation, streaming and application development. I do not assume that Omniverse satisfies every requirement in the diagram or that every application needs all of it. I would evaluate it as a foundation that several applications can build on rather than as the renderer inside one of them.
Where I would still choose the lighter tool
The partner in that meeting did not automatically need Omniverse. If one application owns the 3D, the scene is mostly static, nobody needs to simulate it, and the view exists only to give an operator context, glTF and the viewer they already had may be enough. Adding a platform would create cost without removing a real constraint.
Even a viewer-only project may want photoreal output for the user experience and still need nothing beyond a renderer. For synthetic data or training, I would ask whether the lights, materials, cameras, sensors and physics behave correctly enough for the task. A photoreal result can still have the wrong sensor or physics behavior.
The question for a system architect or developer is whether the project needs only a viewer, or a digital twin that can grow from operational visibility into simulation and optimization:
| Ask | Viewer-only project | Digital-twin foundation |
|---|---|---|
| Who owns the 3D model? | One application. | Several tools and teams contribute while keeping ownership of their source data. |
| How does the scene change? | Updates are infrequent or manual. | Engineering changes need to appear without rebuilding a flattened model. |
| What does the view do? | It gives a person context for alarms, KPIs or other information. | Operating data needs to resolve to equipment in the modeled facility. |
| What does visual fidelity mean? | It is a presentation and user-experience choice, including photorealism if that is useful. | Lights, materials, cameras and sensors must behave consistently enough for simulation or validation. |
| What must be physically correct? | Nothing beyond what a person needs to understand the view. | Physics, contact, motion, timing or sensor response can change the result. |
| Will the scene generate data? | No. The image is for people to interpret. | Controlled scenarios, variation, labels and sensor models support synthetic data or training. |
| Who reuses the context? | One use case. | Several digital-twin and Physical AI applications. |
The right-hand column is where Omniverse becomes a foundation choice. A viewer-only project might still choose Omniverse rendering for visual quality, but that is a narrower decision.
From the manufacturing work I know, those are the needs that make Omniverse relevant. If a project does not have them, I would stay with the lighter tool.
Disclaimer: The views and opinions expressed in this account are those of my own and do not represent those of my employer, NVIDIA.