Developing a Converter Plug-In for Navisworks
JetXR approached us with a request to create a converter plug-in for Navisworks. The task was to develop an algorithm that would convert an NWD model into GLTF format. This project immediately caught our interest—normally, plug--in development involves automating certain routine tasks, essentially replicating user actions through a program. However, this case was different—we had to develop an entirely new functionality that Navisworks itself could not perform without a plug-in.
JetXR specialises in integrating VR solutions into business processes. Their key areas of expertise include UX/UI design, virtual reality and augmented reality, digital analytics, performance marketing, motion design, and more.
The initial idea seemed deceptively simple. GLTF is an open format for 3D models, often referred to by developers as the "JPEG for 3D." Thanks to its openness and versatility, many existing solutions allow models to be converted into this format. The logical approach was to find an intermediate format that Navisworks could export and that could, in turn, be imported into GLTF. However, during testing, we realised that this seemingly simple and obvious method was not viable. The solution lacked flexibility, did not allow for future adjustments, and led to data loss during double conversion.
We then opted for a more fundamental approach. In both formats (NWD and GLTF), model geometry consists of triangular faces forming polygons. Our plug-in "deconstructs" a Navisworks model down to these basic triangles and then reconstructs the model in the new format based on vertex coordinates.
However, there were significant differences between the two systems. For instance, point coordinates had to be adjusted because Autodesk products and GLTF use different coordinate systems. Without adjusting the axis directions, the model would appear "flipped." Additionally, Autodesk's internal units are measured in feet, meaning all coordinates had to be converted before assembling the model in GLTF to maintain accurate dimensions.
Key coordinate system difference: In Autodesk, the "up" direction is defined by the Z-axis, while in GLTF, it is defined by the Y-axis.
To optimise the final model, we implemented instancing—if identical geometry repeats multiple times within a model, it is not redefined each time. Instead, copies of the same element are created, with new insertion coordinates specified. This way, a model consisting of 10 identical elements weighs almost the same as a model with just one.
During the development of the instancing feature, we encountered a subtle but significant issue. Some elements composed of multiple parts would slightly alter their geometry upon export. The individual components would shift relative to each other or rotate. It turned out that in Navisworks, separate geometry parts could have an offset relative to the insertion point. Since GLTF does not support this functionality, we developed an algorithm to adjust coordinates and compensate for the offset.
Examples of sub-element misalignment
In addition to extracting geometry, the client also required the ability to retrieve element properties from Navisworks, as these properties originate from source programs. This functionality was also implemented—the attribute data from the model is recorded in a JSON file, with a unique ID linking it to the corresponding geometry. This allows the client to display element properties in their own software, as if they were viewing the model within Navisworks itself.
As expected, this project proved highly valuable for our team. We gained experience working with primitive geometry and coordinate transformations. For future clients, we can offer the development of a similar converter plug-in tailored to their required format or implement any other idea that requires deep engagement with model structures.
Moreover, having worked extensively with the GLTF format, we are eager to leverage this expertise in new projects, including VR and beyond.