A Speckleverse Adventure Begins: Seizing an Open Opportunity

Upon discovering Speckle, I finally found the crucial missing piece in a complex puzzle I'd been trying to solve throughout my professional life. Speckle's audacious mission to redefine the AEC collaboration landscape struck a chord with me, as it held the key to unlocking siloed data across myriad technologies.

During the "Into the Speckleverse" hackathon 12 months ago, I set out on an ambitious project to encapsulate the entire design review process. At the heart of this endeavour was tight integration with Navisworks, and the project's success gave me the final nudge to bridge a critical gap in the industry by creating the Navisworks Connector for Speckle.

The Driving Force: A Career's Motivation Unveiled

Throughout my career as a Masterplan Delivery Architect and BIM Analyst, I've navigated a landscape of architectural design, geospatial analysis, and intricate data processing. Navisworks and FME have been crucial in my workflows, yet they existed in silos. However, that's where Speckle presented an opportunity that was too enticing to ignore. Its open-source nature and focus on data interoperability positioned it perfectly to become the binder between Navisworks and FME, bridging the chasm that separated these powerful tools.

The idea was simple yet revolutionary: harness Navisworks' capacity for BIM data aggregation and funnel that data into Speckle. Once inside the Speckle environment, this data could be made more accessible and interoperable, thus creating an effortless data exchange with FME for more advanced geospatial analysis and raw data wrangling.

By creating the Navisworks Connector for Speckle, I aimed to unlock the siloed data and integrate the traditionally distinct realms of BIM, GIS, and data wrangling. I wanted to foster a symbiotic relationship between these tools, breaking down the barriers that had long separated them.

This blue-sky thinking was more than just a technical goal. It was a vision of what could be achieved when data is democratised, when different platforms can speak a common language, and when collaboration is not an exception but the rule.

My motivation was, thus, to build a bridge—a bridge that could bring together these diverse platforms, leading to a more integrated, efficient, and intelligent AEC landscape. I saw Speckle as the key to unlocking the potential of Navisworks and FME, and I was determined to turn this vision into reality.

The Navisworks Connector for Speckle was conceived as a solution to the multi-faceted challenges faced by professionals like myself. The goal was to leverage Speckle's strengths—breaking down data silos, promoting interoperability, and fostering collaboration—to revolutionise how we handle BIM data, streamline workflows, and empower data-driven decision-making in the AEC industry.

Tackling the Technological Tangle: A Developer's Journey

The development of the Navisworks Connector was no small feat. It required navigating Navisworks' unique geometric representation and accurately capturing its intricate data hierarchies, a task made more accessible by Speckle's Collection class.

When Autodesk added Navisworks to its portfolio in 2007, it was a calculated move to strengthen its Building Information Modelling (BIM) sector. Despite Navisworks' integration into various AEC workflows, its core technology, originally designed for a time of less powerful processors, remains remarkably unchanged. Despite additional features and cloud integrations by Autodesk, Navisworks' foundational mechanics seem trapped in a past era. This lingering stasis is open to interpretation, whether a sign of enduring efficiency or technological stagnation.

Moving on to the development of the Navisworks Connector for Speckle

Creating the Navisworks Connector was an endeavour that necessitated tackling numerous complexities. Central to these challenges were deciphering Navisworks' unique geometric representation and accurately capturing its data hierarchy. Introducing the Collection class in Speckle was a boon, offering a logical means to handle hierarchical data.

Navisworks essentially reduces models to many fragments, disrupting any ontological or topological resemblance to the originating software's models. Yet, the key to reconstructing the BIM and CAD data lies within the hierarchical data structure of property sets and key-value stores linked to these fragments.

Translating the geometric data requires understanding and unravelling Navisworks' mesh language, which disassembles each geometry object into individual components with unique transformations. Navisworks' practice of eliminating duplicate faces adds to this complexity, using an instance definition model instead.

Navigating this geometric maze demanded an understanding of Navisworks' underlying C++ COM interop, the alternate mesh representation of Speckle, and a keen grasp of Speckle's C# SDK.

0:00/1×

Try Speckle Here

In developing a Speckle Connector, we followed a three-step paradigm common to other Connectors in the family: 1-Selection (Connector), 2-Conversion (Converter), and 3-Commit (Connector). This process, while structured, was not without its challenges, owing to Navisworks' arcane APIs and the complexity of its data representation.

The Connector operates as a .NET application inside Navisworks using the .NET Add-Ins framework. Speckle's robust SDK and toolkit were instrumental in easing the integration process. We could transform the data from Navisworks models to Speckle objects by leveraging the Speckle SDK.

Sitting comfortably within the .NET family of connectors meant utilising the existing DUI and then DUI2 interfaces was straightforward and allowed me to concentrate on the Navisworks interfaces rather than struggling with many problems simultaneously. The original hackathon entry was partly smoke and mirrors as the same Node server was running and powered the UI for both the web app and the plugin. Much of this was achieved by hacking around with older versions of Speckle gathering dust. Developing a UI for a Speckle plugin using a web application stack fitted what I was already very knowledgeable doing and was extremely flexible. The fact that the next generation of DUI3 is considering the same pattern is belatedly reaffirming. 😀

Unlocking Navisworks' mesh language, manoeuvring its underlying C++ COM interop, and leveraging Speckle's C# SDK was part of the technical odyssey. The three-step paradigm of Selection, Conversion, and Commit, typically adopted for Speckle Connectors, was instrumental in guiding this journey. Despite the complexities, the effort paid off, and the Navisworks Connector for Speckle emerged as a successful endeavour. There was so much good work done by others in the Speckle team that while the Conversion was unique, the Interface and Commit were easy-to-adopt templates.

Community Spirit in Action: The Power of Collaboration

This accomplishment is not merely a reflection of my individual effort. It is a testament to the cooperative spirit of the Speckle community and the potential of community-led development. The Speckle team, always ready to lend a helping hand, has fostered an environment that encourages and supports developers keen on creating new Connectors or applications.

This level of support is open to anyone — individuals, independent teams, or first-class application vendors. The Speckle platform’s flexibility, extensive documentation, and active communication channels are a beacon, inviting developers to bring their visions to life. In addition, the Speckle Community is a willing gang of testers and a positive ideas feedback loop.

Join Our Community Today!

A Continuing Journey: The Road Ahead

Developing the Navisworks Connector for Speckle was both challenging and thrilling. As a member of the Speckle team now, my aspirations for the Navisworks Connector are twofold. Firstly, I hope that it continues to aid teams in streamlining their workflows, fostering better collaboration, and optimising their resources. Secondly, I envisage this Connector to inspire others in the community, much like it did for me, to seize the opportunity and contribute to expanding and enhancing the Speckle ecosystem. I actively seek opinions on what workflows beyond those I know we could be supporting.

The journey of the Navisworks Connector for Speckle, from inception (0) to a fully functional tool (60), demonstrates what can be achieved when a supportive community and the right resources empower you. Remember, though, this is just the start. There's still a vast terrain of potential to be discovered. The best is indeed yet to come.