We’re stoked to add Navisworks to the Speckle family allowing you to share and work with even more of your AEC data, and it’s available in alpha !
This send-only connector is developed and supported in-house and is available for installation through the Manager.
The connector supports basic 3D geometry node conversions from Navisworks Manage versions 2020-23, with additional conversions on the immediate roadmap:
full property translation, and
- correct Y-Z orientation.
Also, on the imminent feature support agenda:
- Origin translation
- Custom overrides support (colour, transparency, location)
We have many ideas for further supporting your AEC workflows. To focus our efforts, we’re extremely keen to hear how you’d like to use your Navisworks data within your Speckle portfolio. The best place to let us know is here on the Community forum.
Note: Check out the repo for constant development and updates; the codebase of an alpha connector is by its nature in flux; code-fix contributions may be premature.
Now available in Manager as a release candidate version 2.11.0-rc1.
The XY orientation issue is fixed and will hit the manager in 2.11-rc4!
I’ve installed the Naviswork connector but the Speckle tab is not loading on Naviswork Manage 2024, any idea how to possibly resolve?
Many thanks in advance
2024 support will be with our forthcoming 2.14 release - you can either wait a couple of weeks or try it out already by installing our WIP
Then you’ll be testing a pre-release of the WIP of an alpha version connector.
thanks J! worked great.
The geometries have lost their names and layer structure when pulled on the Rhino side, but I guess that’s in the development roadmap
It is and it isn’t. And tackling what should be can depend on user feedback like yours. It may be that development in Rhino Connector is needed … or … in Navisworks.
Right now, the data structure of the Navisworks commit directly maps to the depth of the hierarchy you send.
And we working hard on making that web view even better, but there is a match
How this should appear in Rhino is up for some debate.
That same commit receives in Rhino as:
But in a previous release you would receive a layer structure that was like this:
The majority of Data properties are also not present.
Also not ideal. We’ll get there, but something we’d like to support if you can describe the workflow that requires it!
I give you an example.
I use both Rhino objects names and the layer tree structure to automate classification of objects for quantity take-off or to work as structured drivers for later processes.
Retaining the FBX structure would help to keep objects structured on the Rhino side as well, instead of a flat layer.
The structure is there, and with Grasshopper, Dynamo, python, .Net and even PowerBI to some extent - this is certainly how you will access things.
I will talk with the Rhino crew if there is a different outcome that should be possible.
Just tried the connector for the first time as I needed to send some Navisworks data to Rhino. Worked out amazingly well, thank you!