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.
I used the newest public WIP (9.0.26006) to compare to my list of wishes and have a few notes and suggestions.
Improve the geometry type and name…
For the most part OK since RH-90852.
Please put the canonical geometry name into the Type property if it has an object name.
Use the proper marking for group nodes…
For the most part OK since RH-90852.
Please change the group node to “Composite”, so that the default “Last Object Selection Resolution” in Navisworks stops there. Note that this might also enable the “Auto Merge” of its nested geometries, which should be disabled. Can be done with LcNwcGroup.SetComposite() and LcNwcNode.SetEnableAutoMerge(false) if using the nwcreate library.
Support for more object types…
For the most part OK since RH-90852.
Please support point and point cloud geometries; could be added without much hassle by LcNwcGeometryStream.Point() if using the nwcreate library.
Support for layer/object colors…
For the most part OK since RH-90852.
Please add the Transparency/Alpha values for layer and object colors.
Add support for applying a transformation…
May be solved by allowing the user to pick a named cplane which represents the “shared/global” coordinate system. Then take the change of basis transformation between the named cplane and rhino world plane for LiNwcScene.ApplyTransform() if using the nwcreate library. I know that another plugin for similar formats, such as the Geometry Gym IFC export plugin also use this approach.
Allow to export NWC cache files…
OK since RH-90852
…object properties […] user text…
OK since RH-90852
…block instance […] placed onto the corresponding layer…
Sorry, I was wrong, block instance object user text currently does not get exported. I checked again and it only works for regular (non-block) objects.
EDIT: It does work, you have to select the actual instance object in the selection tree.
-It seems that text and curves do not come through if they’re inside of a block.
Below, I copied all the objects into a block and only geometry with breps/surfaces came through:
-Running the ExportNavisworks command will export just about everything (including Off layers). While I can definitely understand cases where you’d want to do this, it may be more user-friendly to make this an option in the command bar. I tend to use lots of construction geometry and “options” in layers and my clients don’t need to see them. File>Export Selected isn’t a bad workaround now, though.
-Text that does come through is often in weird orientations/scales. Some of them in inexplicably backwards or upside down. I know that Rhino is nice in that it changes orientations based on the camera-- but I want to know what the “true” orientation is before exporting. I’m having to explode text into curves one-by-one to see what’s going on.
I use transparency (or ghosted object display modes as mentioned above) to show services spaces/space reservation on equipment, to indicate hazardous areas, etc. I can modify stuff in Navisworks after the the export, but it’s a huge drag editing anything in Navis
-Finally (maybe this is a big ask?) but it’d be great if the ByParent properties could come through (even if it’s just the object color/material) on block objects. I set all 99% of blocked object’s properties to ByParent.
