(1) Overview
Introduction
Due to advances in engineering tooling and computing, digital twins have emerged as a powerful solution to facilitate design validation, monitoring, and simulation in a single unified environment [1]. A digital twin provides a virtual representation of a physical system, integrating real-time data, simulation, and visualisation within a shared environment [2]. This capability is valuable in complex engineering domains, such as nuclear, where the ability to iterate rapidly on designs, simulate operational conditions, and predict system performance may help accelerate development timelines [3]. Given the complexity associated with fusion machine design, a robust and extensible digital twin ecosystem is needed.
The DBO-IM (Design, build and operation of fusion power plants in the industrial metaverse) project [4] was initiated out of this need, with the aim of providing digital tools required to speed up the development timelines for fusion machine design and manufacture. A technology driver for this project is the use of NVIDIA Omniverse, which is a platform of APIs, SDKs, and services which enable developers to integrate simulation, rendering, and sensor data into a single 3D space [5]. In this 3D space, creators are able to work independently on their corresponding parts using a wide range of tools while supporting updates and changes across them [6].
For the DBO-IM project, Omniverse serves as a shared 3D object exchange where contributors can collaborate on the same model all while simultaneously conducting simulations in a true-to-life virtual scene [5]. Such scenes are represented by Omniverse in the Universal Scene Description (USD) format, which is an open 3D model and scene format designed for efficient storage and streaming of 3D data [7]. Initially intended for use in the visual arts domain, USD has been shown to improve the productivity of 3D pipelines [8]. USD files are hosted in an Omniverse Nucleus instance, which is its storage and collaboration hub [5]. As the digital hub for 3D objects, the Nucleus receives data through Omniverse connectors, which act as the interface between third-party applications and the Nucleus platform.
The Omniverse distribution provides a selection of connector software to other content-creation applications which allow 3D data to be pulled into USD scenes [10]. Omniverse also provides a CAD Converter extension available as a GUI tool for users or as a standalone service for batch conversion of CAD files into USD [11]. The extension can generate new USD files which can then be referenced in other USD scenes. However, it lacks support for CAD assemblies and instead merges components into so-called flattened USD representations [11]. Such representations store the entire geometry of all components in the scene in one file. This is sufficient if the use case is simply for visualisation, but not for workflows which require multi-component design iterations.
In any engineering workflow, CAD remains the starting point of the design process, defining geometry prior to use in other tools. For such a digital twin ecosystem to be effective, data such as CAD models must be easily exchangeable with other elements within the system [12]. The Omniverse connector for FreeCAD has been developed as part of the DBO-IM project and born out of a need for a CAD operator able to generate parametric and directly modelled CAD geometry for engineering that seamlessly integrates into the Omniverse platform. FreeCAD is an open-source general-purpose modelling tool originally developed in 2002 for mechanical engineering and product design applications [13]. Since then, its community maintainers have released regular software updates, and its functionality has been extended to a wide cross-section of engineering disciplines [13]. It is often viewed as the most comprehensive freeware CAD tool among systems of its type [14]. For the DBO-IM project, an ‘upstream source’ of CAD was required, and thus FreeCAD was selected due to its extensibility, ease of development, active user base, and its ease of use for both parametric and hand-modelled CAD geometry.
Implementation and architecture
Key terms
Prior to an explanation of the software implementation and architecture, it is useful to establish an overview of key terms that will appear throughout this work.
One of the most widely used file formats in computer-aided design (CAD) is the STEP file format (Standard for the Exchange of Product Data). STEP is a neutral format, meaning it is not tied to any single proprietary CAD system, and is compatible with most CAD software currently available. CAD models in STEP can be represented in several ways, one of the most common being the boundary representation (B-Rep) format. B-Rep describes 3D geometry in terms of the boundaries that enclose a solid object, typically surfaces defined by precise mathematical functions. These functions may represent the geometry in a discrete form, alike to a surface mesh, or in a continuous form, describing smooth regions.
STEP is not the only format of interest. We have also introduced USD (Universal Scene Description), a framework developed for the interchange and scalable composition of 3D data. A USD file is built up from scene elements called primitives (prims), which can represent geometry, materials, shading, physics, or other attributes of a scene [9], henceforth referred to in this work as USD prims. These USD prims come in various types; in this work, we focus primarily on geometric ones. These can include basic shapes (e.g., cones, planes, spheres) as well as meshes (UsdGeomMesh).
Another important USD concept is the Reference. A Reference acts as a pointer from one USD prim to another. When the referenced USD prim changes, any USD prim that references it is updated automatically. Importantly, the source USD prim does not need to reside in the same file as the referencing USD prim, allowing large and complex scenes to be composed without duplication of data. Additionally, this enables non-destructive editing, since changes to the source USD prim propagate to other referencing USD prims.
In the context of this connector, an asset refers to a single CAD part stored on the Nucleus server as a STEP file, used for CAD editing and a corresponding USD file, intended for Omniverse interoperability. An assembly refers to a collection of assets combined into a single USD scene using References. These concepts form the foundation of the connector’s design, which is described in the following section.
Architecture
The connector software developed is packaged as a FreeCAD workbench written in the Python programming language. Its graphical user interface (GUI) is written using the PyQt5 package. All software functions can be triggered via the workbench task or ribbon menus, available upon loading the Omniverse Connector workbench on the FreeCAD GUI. The overall software architecture consists of 2 layers, as illustrated in Figure 1:
Figure 1
Software architecture of the FreeCAD connector for Omniverse.
FreeCAD Layer – This layer handles user interactions via the GUI and translates them into function calls.
Omniverse Layer – This layer manages geometry conversion, manipulation of USD scenes, and interactions with Omniverse Nucleus. This layer is dependent on the Omniverse Client Library [15] (for communication with Omniverse services), Open3D [16], and OpenUSD [17] (for converting CAD geometry into USD format).
User interactions within the FreeCAD GUI are processed by the FreeCAD layer, which then translates them into commands for the Omniverse layer. Small data exchanges (e.g. username and connection status) are retrieved directly from the call’s output, whereas larger data is temporarily stored in the local filesystem before being processed by FreeCAD or Omniverse. The temporary directory is cleaned after every user session.
Data storage and geometry conversion
STEP and USD differ fundamentally in how they represent geometry. STEP supports continuous B-Rep surfaces, which describe solids using mathematically defined surfaces, while USD does not, and instead relies on geometric primitives (such as spheres, cones, and cubes) or through polygon meshes and subdivision surfaces, controlled via USD’s subdivisionScheme attribute.
When a user updates geometry in FreeCAD, the connector commits the change to STEP and then tessellates the updated model into a USD mesh prim (UsdGeomMesh). In this way, each asset on Nucleus maintains two synchronised representations: the authoritative CAD model in STEP and a lightweight proxy in USD suitable for Omniverse workflows. Note that the USD representation implemented in the connector is the polygon mesh (subdivisionScheme = “none”).
Rather than allowing round-tripping between STEP and USD, the connector enforces a forward-only workflow in which geometric data is only pulled from the STEP representation of the CAD model. Here, the geometry’s STEP representation is used as the authoritative CAD model, while its USD one acts only as a lightweight proxy. This separation of roles avoids the need for inverse conversion, which is computationally expensive and prone to inaccuracies, and ensures that CAD fidelity is preserved across iterative updates. To the best of the authors’ knowledge, this concurrent use of STEP and USD files within a single CAD workflow has not been previously reported in the literature. However, the practice of treating USD files as lightweight proxies for visualisation or assembly is consistent with approaches taken by other unidirectional Omniverse connectors for third-party software [10]. The difference is that in this connector, the STEP file is also retained, and its geometry can be pulled back into the third-party software.
As illustrated in Figure 1, when a user commits a change in FreeCAD, the geometry is exported in both STEP and STL formats. The Omniverse layer processes these outputs by converting the STL into a USD mesh using Open3D [16] and OpenUSD [17]. Both the STEP file and the generated USD file are then uploaded to Nucleus via the OmniClient library [15].
Once uploaded, assets are organised into project folders on Nucleus, located under $HOST_NAME$:/Projects/FreeCAD or $HOST_NAME$:/Users/$USER_NAME$/FreeCAD for private projects. Each project contains two subdirectories, shown in Figure 2. The assets folder stores individual parts in both STEP and USD formats, with each USD file containing a single USD mesh prim representing a single part. The assembly folder stores USD assemblies that reference these USD asset files together with their positional attributes (e.g. translation and rotation). Because assemblies rely on USD References rather than duplicating geometry, changes to an asset automatically propagate to assemblies, and storage requirements for large assemblies can be minimised. This makes the workflow more efficient and scalable.
Figure 2
A generic file tree of a sample CAD project created using the developed software.
Version control & metadata
Having outlined how assets and assemblies are stored on Nucleus, it is equally important to consider how these files are managed across successive edits. For this purpose, the connector makes use of Omniverse’s built-in version control system, which manages file history through “checkpoints”. Each checkpoint captures the state of a file at a specific point in time and remains immutable once created [18].
With every upload, download, or assembly operation performed via the FreeCAD connector, a unique string token is attached to the checkpoint message, which allows users to track different versions of the asset. This token can be viewed by the user on both the Nucleus GUI and the FreeCAD GUI, where it is attached as an object property. STEP and USD files that share the same token are linked to the same task to maintain consistency. For instance, when a user creates a new assembly from multiple CAD assets, the generated assembly file and its associated asset files will all carry the same token. This allows for tracking of asset history from its initial design to its use in assemblies. The checkpoint message also describes the task that was done to the asset or assembly. An example of checkpoint messages of an asset is shown in Figure 3.
Figure 3
Checkpoint messages in the Nucleus UI for different file types, each with the token and task description: (a) USD file of an asset, showing its creation and addition to an assembly. (b) STEP file of the same asset, showing its creation and pull-to-FreeCAD operation. (c) an assembly file, showing when an asset was added and their position modified. The message also indicates the user and timestamp associated with the task.
Users can revert to earlier versions via the Omniverse Nucleus browser, although this action is not currently available through the FreeCAD interface. At present, Omniverse supports only a single linear branch, named “default”; branching and merging functionality is not yet available but is expected in future releases [18]. Consequently, the versioning model is currently sequential, and each update creates a new checkpoint without the ability to fork or merge versions.
Usage
With an understanding of the underlying architecture, data management, and version control established, we now turn to the user-facing workflow of the connector. Users interact with the connector through a dedicated FreeCAD workbench interface (Figures 4 and 5). The interface provides access to tools for connecting to Nucleus, editing CAD assets, managing assemblies, and synchronising changes. Here, we provide an overview of sample workflows that can be carried out using the FreeCAD Connector for Omniverse, describing the goals, user tasks, and program routines. For detailed step-by-step instructions on the use of individual functions, the reader is referred to the project documentation available in the software repository.
Figure 4
Connector ribbon menu buttons. 1 – Pull to FreeCAD, 2 – Push to Nucleus, 3 – Settings Panel, 4 – Assembly Panel.
Figure 5
The (a) settings and (b) assembly task panels of the Omniverse Connector workbench.
To begin, users must first load the Omniverse connector workbench into their FreeCAD workspace. Users can then connect FreeCAD to a valid project on the Nucleus server. This is done by entering the settings panel (Figure 5a), which provides a set of options for the user to configure their connection. A new project can be created by selecting “Create new project”, which triggers a call to the Omniverse layer and generates a project folder on the Nucleus instance. The Omniverse layer then verifies access permissions and loads the project if successful. Alternatively, users can connect to an existing project by selecting “Open existing project” and providing a valid project URL; in this case, the connector simply checks if the user can connect and has access permissions to the specified project.
Once a project is loaded, the user can list available CAD assets through the “Browse project assets” option in the settings panel (Figure 5a), which displays them in a drop-down menu. To import an asset, the user selects “Pull to FreeCAD” on the ribbon menu, after which the file is imported into the FreeCAD workspace. New assets can likewise be created from the settings panel by providing a name, after which the asset entry is added to the project. Editing of the geometry can now begin, as a project has been specified and an asset selected; this status is also indicated in the settings panel.
Updating Nucleus assets involves exporting the modified geometry from FreeCAD and uploading it in both STEP and USD formats. When the user selects “Push to Nucleus”, the connector exports the model to STEP and STL, tessellates the STL into a USD mesh prim using the Omniverse layer, and then uploads both STEP and USD files to the designated asset location.
With individual assets stored in this way, the connector also supports the creation and management of multi-component assemblies. Users can either create new assemblies or import existing ones. New assemblies are generated in FreeCAD by first pushing the required assets to the Nucleus project and then selecting the “Create new assembly from workspace objects” option. This produces a USD file that references the chosen assets together with their positional attributes. Conversely, existing assemblies can be reloaded into FreeCAD using the “Import existing assembly into workspace” option, which prompts the connector to fetch the referenced STEP files and position them in the workspace according to the assembly description in the USD file.
Synchronisation between local and remote assemblies is supported in two ways. On demand, assemblies can be updated by uploading modifications from FreeCAD or fetching changes from Nucleus, using the “Upload assembly changes” and “Fetch new assembly changes” buttons on the assembly panel. In addition, the connector also supports a live assembly mode. Users first connect to an Omniverse live session, which will then update component positions in FreeCAD in real-time based on data streamed from the Omniverse layer.
Quality control
The FreeCAD Connector for Omniverse has undergone testing to ensure stability and usability. Testing was carried out in different environments, including Windows 10/11 and FreeCAD 0.20+ (1.0 release included).
To support long-term maintainability, automated unit tests have been developed and integrated into the project. These tests focus on the core functionality of the connector, including authentication with Nucleus, asset import and export, and synchronisation operations. Specifically, the tests simulate key stages of the typical user workflow—such as connecting to a project, verifying access to asset files (Both STEP and USD), downloading and uploading STEP files, and uploading USD files. In addition, a test checks if the connector module can be successfully imported into FreeCAD’s Python environment. Since integration failures often manifest as import-time errors, it provides an early indicator of compatibility issues, particularly important now that FreeCAD is undergoing more development following the release of v1.0.
Functional testing focused on end-to-end workflows, starting from the login stage before ending with exporting back to Nucleus. This initially revealed issues with inconsistent error reporting and handling missing geometry, which were then rectified in the current release of the code. It is expected that with further use more updates will be made to the software.
Load testing was performed with large assemblies and STEP files. As expected, some slowdown occurred, particularly with the largest tested files—a 300MB STEP file with a 1.93GB counterpart USD and an assembly containing 20 components. The slowdown is dependent on the user’s internet connection and whether the Nucleus instance is hosted remotely or locally. Pictures of the two objects are shown in Figure 6a and 6b. While performance remained within acceptable limits, these tests highlighted potential areas for optimisation when handling heavier models.
Figure 6
Omniverse renderings of (a) the largest single-asset model tested – an inner vessel of a stellarator fusion device (1.93GB), and (b) the largest assembly model tested – a parametric tokamak fusion device (20 components).
Some limitations remain in the current implementation of the software. Assembly functionality is partially supported but still under development. At present, live assembly updates are supported only from Omniverse to FreeCAD; live updates from FreeCAD to Omniverse are not yet possible. Another limitation is that the connector does not resolve assembly reference links across different Nucleus instances. For example, if an assembly references assets hosted on a different Nucleus server or the server hostname has changed due to migration, these references may fail to resolve correctly. Additionally, importing assemblies with many complex parts can be slow due to the size and complexity of the associated STEP files. Users are currently limited to working on one assembly at a time, as switching between assemblies requires a full re-import. This is a known issue and is planned to be addressed in a future update. Finally, although project discovery on Nucleus is not yet implemented, users can still connect directly using the full project URL. This limitation may be lifted in future versions depending on demand.
The connector is released as open-source software, and community contributions are encouraged and welcomed. Users are able to download the software via the GitHub repository specified. To verify correct installation and operation, users can follow the automated unit test sequences provided in the software repository. Please note that the user will require access to an Omniverse Nucleus instance.
(2) Availability
Operating system
Microsoft Windows ≥ 10 Home/Professional.
Programming language
Python ≥ 3.10
Additional system requirements
There are no specific additional system requirements.
Dependencies
User must first install FreeCAD ≥ 0.20. Open3D, and Omniverse Connect Sample v202.0 are pulled automatically during installation. Access to an Omniverse Nucleus instance is required.
Installation
Installation steps are included in the documentation available at https://github.com/Metaverse-Colab-for-Fusion-Energy/FreeCAD-Omniverse/tree/master/docs.
Note on Omniverse Nucleus setup
At the time of writing, NVIDIA is in the process of migrating Nucleus deployment to distribution via the NGC catalogue (expected by October 2025). Due to this transitional phase, we do not provide detailed instructions for setting up an instance of Omniverse Nucleus. Users are advised to consult official NVIDIA documentation for the most current installation guidance.
List of contributors
Raska Soemantoro (developer)
The project includes sources from Omniverse Connect Sample v202.0. https://github.com/NVIDIA-Omniverse/connect-samples, which is licensed under the MIT license.
Software location
Archive
Name: Zenodo
Persistent identifier: DOI 10.5281/zenodo.14866087
Licence: BSD 3-Clause License
Publisher: Raska Soemantoro
Version published: v3.0.3
Date published: 13/02/2025
Code repository
Name: GitHub
Identifier: https://github.com/Metaverse-Colab-for-Fusion-Energy/FreeCAD-Omniverse
Licence: BSD 3-Clause License
Date published: 13/02/2025
Language
English
(3) Reuse potential
As a FreeCAD workbench, the Omniverse connector provides a practical way for users to bring parametric CAD models into Omniverse without relying on proprietary software. While its primary purpose is to serve as a bridge between FreeCAD and Omniverse for visualisation, simulation, and collaboration, early testing has shown its role as both a practical tool and an example of OpenUSD adoption in engineering design, and thus it also demonstrates a broader approach to working with USD files and engineering CAD (STEP).
The USD format is increasingly being used in many fields which utilise 3D content, with many software tools now natively supporting it – the Alliance for OpenUSD, which comprises multiple software companies, have been working on promoting its use [19]. As USD adoption expands, it is anticipated that CAD tools like FreeCAD will eventually offer native support for the format. With such developments, it is expected that work will be done that further harnesses USD’s capabilities for use in engineering design. This work represents the first initiative within the FreeCAD community to integrate USD, laying the foundation for broader adoption of the standard.
Although the connector is currently built as a FreeCAD workbench, parts of the implementation, such as the routines for converting STEP to USD, and functions for uploading and downloading assets between the local machine and Omniverse Nucleus, are written as standalone Python routines. These routines may be adapted for other CAD environments or for batch-processing workflows that require USD generation outside the FreeCAD GUI. In its current form, the connector is tightly coupled to the FreeCAD GUI API. In fact, it is possible for the user to call such routines via the command line, as with most FreeCAD workbenches, but the underlying Omniverse interaction layer could also be modularised in future versions.
Planned improvements may include exposing the Omniverse routines as a standalone Python package or adding native capabilities to FreeCAD itself, following the patterns used by other 3D tools like Blender and Unity. Contributions toward these directions are welcome, and the source code is available for extension via GitHub.
Notes
Omniverse Nucleus™ is a trade mark of the NVIDIA corporation.
NVIDIA Omniverse™ is a trade mark of the NVIDIA corporation.
Acknowledgements
We thank Eric Bowman of the Nvidia Corporation for his advice on connector software architecture.
Competing Interests
The authors have no competing interests to declare.
Author Contributions
Raska Soemantoro: Software, Integration, Quality Testing, Writing – Original Draft, Writing – Review & Editing.
Lee Margetts: Conceptualisation, Writing – Review & Editing, Funding acquisition.