We have had several requests to support data exchange with Navisworks, a project review application for architecture, engineering, and construction professionals.
The Rhino WIP now allows you to save or export Rhino geometry, and other information, to Navisworks .nwd documents.
I was able to generate a Navis file and open it in Navisworks Freedom within 5 minutes of installing the Rhino WIP.
Couple items jump out right away:
Can we have an option to export the Rhino Object User Text as custom properties?
Can we have an option to set the object material colors in Navisworks to match the Rhino object colors instead of material colors? Maybe its a switch to use Material properties or Object colors?
In the Navisworks Selection Tree blocks currently get dumped into their own individual sublayer branches. If you have a lot of blocks this can bloat the selection tree. Can the blocks be placed on a “Block” parent layer so that they can be better isolated? It would be even nicer to keep the blocks on their parent layers within the larger tree but I understand if that might be complicated given a block can have multiple layers
Improve the geometry name and type. Currently everything is either a curve or a mesh - use the Rhino canonical geometry type name for the Navisworks name and type property (surface, subd, polycurve, etc.)
If the geometry has an object name, write the Rhino type into the Navisworks type property.
Use the proper marking for the group nodes. Group nodes can be marked for their purpose: “Layer”, “Composite”, “Insert”, “Collection”. This mostly affects object selection and clash detection filtering, also the icon in the selection tree.
Support for more object types. In my quick test the current WIP did not export nested block instances, and some block instances had an unexpected color. I will provide some examples below.
Support for layer/object colors (“shaded mode”) and material colors (“rendered mode”). As @NavArch stated, have a toggle to use either the layer/object colors or the material colors. Make sure that everything looks like expected (“WYSIWYG”). This includes transparencies/alphas.
Add support for applying a transformation to the export. Most of the time Navisworks is being used to combine models of different disciplines/sources which should all get exported using a transformation to end in a “shared/coordinated” coordinate system. Note that this does not change the Rhino internal coordinates, its just that translation and rotation values are written to the file as metadata. Most projects I worked on these were Easting(X), Northing(Y), Elevation/Datum(Z) and Rotation to North (Z-Axis) values to get the model to reflect the site’s survey coordinates when loaded in Navisworks.
Allow to export NWC cache files. I’ve had projects where it was expected to deliver NWC only, no NWD (for whatever reason). As far as i know you’d need a licensed/paid Navis install on your computer to allow saving NWD but not for NWC - at least for the nwcreate API. However maybe this has been changed recently or I misremember.
A lot of Navisworks functions depend on rich object properties for selection, filtering, clash detection, quantity take offs, time lining. If there’s a Rhino object or document attribute available that could be useful - write it to the file. Just like the usertext @NavArch mentioned.
For block instances, I’d argue that the block instance itself can be placed onto the corresponding layer node which the block instance also uses in the Rhino document.
I’d also like to discuss the pro/cons of appending a consecutive number to every object. I’d argue that its not necessary because you cannot find this number in the original Rhino model anyway, also if you want to identify/find/reference a certain object there’s always the GUID. IMHO
I can elaborate further if needed, but this is already a long post.
A couple years ago I had the “pleasure” writing a bespoke Navisworks exporter for Rhino. It’s a RhinoCommon plugin which p/invokes the nwcreate API. That’s when I experienced the things I listed above.
Nevertheless - I prefer having an official exporter to maintaining my bespoke plugin. So again - cheers!
I cannot share the bespoke plugin, but here’s the 3dm file and exports from both the Rhino9-WIP and my bespoke plugin for seeing the differences (zipped - cannot upload nwd yet) examples.zip (3.6 MB)
I’m open to alternate solutions but my suggestion above was the easiest thing to come to mind. Similar to @mikeJM comment 8, the preferred solution would be to place the block geometry on the layer node that is used in Rhino. Now the issue I see is what to do about blocks that are used in multiple places and are placed on different layers.
Take the example below:
Say I make a door block with sublayers for the door frame and door position. Then I copy that block to Room 1→Wall→Door and Room 2→Wall→Door. If you just export all the block geometry to the 2 door layers for their respective rooms you get visibility control by room layer, but both the open and closed door would be visible at the same time. The current solution actually is worse in that a new top level layer is created for each block, and then all the geometry is dumped under that layer losing any easy visibility control.
If we are stuck with the current solution all I was suggesting is that all the individual parent block layers get placed under a single top-level selection layer called Blocks. That way if you have 50 blocks they aren’t cluttering up the selection Tree.
As I was writing this reply I think I might have come to an even better solution. Why not just duplicate each blocks’ sublayers under the main layer that the block is copied to? So in NAVIS the selection tree would look more like this:
Yes there are new branches in the NAVIS Selection Tree that don’t mimic the Rhino layer tree but you at least keep all the visibility functionality that you had in Rhino.
Dale,
Regarding Object color, I read your suggestion in Youtrack about using object color for now. Seems more likely that users will have set object color initially compared to setting materials so my vote until you can add selection options to the user form would be to use Object color.
I will add that in Rhino we like to set windows SetObjectDisplayMode to Ghosted so that they can be transparent while the rest of the model is . It would be Slick to include transparency as an option, but maybe that will need to be reserved to materials.
The “block instance” nodes always contain the reference to the “block definition” node.
That’s how exports of other “block/reference aware” cad software look, and that’s how my bespoke exporter does it as well.
In my opinion that is the most faithful representation of the Rhino model. The different node types (as seen by their icon) also ensure that the usual Navisworks functions work as expected, even if this looks like “selection tree cluttering”.
But hey - I’m going to accept anything McNeel considers “good enough” for them to invest more work into “yet another export format”. Let’s see how far they are willing to go.
