We are wrapping up a massive programming effort at the office that had 8 separate working Revit models across 8 disciplines and 12 Plant3D models for 2 disciplines. In total, Navisworks is reporting the following statistics:
- Unique GUIDs: 149,963
- Total Triangles: 12,758,863
Keep in mind, I said programming models. In most firms, this means mass models, that at best have some walls and key model components. This model acts more like a SD or DD model in many ways but the client required this level of detail to ensure a solid programming effort.
I gave this preamble to illustrate a point. As models get larger and more complex, the structure of how models are broken up becomes a major concern. Not only in Revit (Sorry, that is for another post) but also for Navisworks. I firmly believe that Navis is a key player in the lifecycle of a BIM project and that it does serve more than a clash detector. Ok… enough of the rant.
As I started to say, Model structure is important in Navisworks. I started this programming effort with the intent of not building a navis model until the design phase of the project. However, it became quite apparent within weeks that I needed to add it into my efforts. I took a very standard approach at the beginning. I exported each model as a 3D view and aggregated the model together in Navis. It worked fine for a while. When I say it worked, I mean it allowed folks to “look” at the model . Interaction; not so much.
Next Logical step: Break it down by level. I broke each model down by level and created a Floor plan in revit, that had a view range that went level to level. I then associated that to a 3D view and Viola .. Model is broken down to each level, ready for navis exports. Awesome.
Well that was awesome, for a total of 2 weeks. Why? Changes. This project rapidly changed. It seemed as if it changed directions each day. For model management, this was somewhat of a nightmare. What I learned quickly was that If you use a View-Oriented 3D view for each level of the model, it was a static sectionbox. Most of you would say, ‘well ya’ but have you really thought about what impact that has downstream for Navis? You end up with a striped building and loss of important model data.
So after thinking and testing and irritating a few folks, here is the result of what we did.
We segregated the model into worksets by level. YIKES! For this project, each model ended up with between 20-25 worksets per discipline. While this may seem extreme for some, it had its distinct advantages.
- It allowed each discipline to isolate data for areas of the building.
- It allowed for easy segregation of Design options (There were just a few options along the way)
- Allows for easy worksharing for larger groups. Each person can work in one area with minimal impact to other folks ( Kinda a moot point with me, as I tend to make people work in a ‘borrower’ mode)
- Allows for easy 4D modeling downstream in Navisworks
Allows for easy model separation in design development
- Each workset will eventually be broken into separate models
And lastly, the breakdown allows for flexible Navisworks Exports. How? Well each floor had an export view and that view was isolated to a single workset. This means that as the workset grows (X,Y and Z) the view is already up-to-date and is not limited to a section box that could potentially cut-off any data. (Which definitely happened when we had things boxed down earlier in the project)
So now comes my favorite part. How do you organize the model on the navis side?
Im going to skip over the idea of directly importing Revit models to Navis for this post. I will get to that soon enough. For this excercise, It will be done the traditional NWC route. Carry on …
Well, you could import all the NWCs at once and be done. I did that for a few weeks. Let me tell you and save you a few annoying hours, it’s a bit aggrevating to sort through (note: sort) all the appended NWCs in navis. Mainly because Navisworks does not allow you to SORT imports! So you need to add the NWCs in the correct order to stack discplines models together. Seriously annoying, if you get one wrong… you need to delete them all from the NWF and try again. I got smart quick though. I remembered from somewhere that Navis ships with a great utility. Batch Utility
This seemingly benign utility saves me a few hours a week now. Basically it allows you to schedule the aggregation of NWC/NWD files into a NWF file at any increment you would like. So I used it to my advantage. I made a folder of discipline NWF files that contain all the NWCs from that discipline. The NWCs are overwritten whenever the discpline
(meaning a single lead modeler from each discipline) export the changes from Revit and then the Batch utility recompiles/refreshes the NWFs. Great!! So what?
Once the discpline NWFs are refreshed, the Batch utility overwrites a single NWD for the discipline in a set folder. AH Ha! If any Navis savvy folks are still reading this, you know where I am headed. Once these NWDs are created, I have a single NWF file that takes these discipline NWDs and mashes them together. This gives me a very clean, very organized and sustainable structure that I can quickly create (literally takes 5 minutes now) and archive. The best part to me is that we archive a full-model NWD that can be overlayed to see these changes from week to week if needed.
Here are some of the advantages to this methodology:
- Additional modeling is easily updated through automatation
- Any additional NWCs are easily added to any discipline without having to rebuild the entire model structure
- FILTERING! Based on the way that Navisworks is structured, When a NWD is added to an NWF, the tree structure is preserved. This means that if you hide the NWD, the entire discipline can be shut off. If you open the NWD’s tree you can isolate a single level or set of levels.
- Data Fidelity. I am not concerned that a section box is potentially cutting off data.
- Speed. We noticed a marked improvement in refresh/rendering of our walk throughs in navis
- 4D Modeling. This method allows a quick way to stack the model in a basic 4D animation. Great for showing stakeholders/ design leads
This structure is easy to understand for new users.
As we all know, even the best solution has its downfalls. For full disclosure, here are some of the drawbacks:
- Initial setup. It takes some time to restructure the revit models to be segregated into these worksets if there has been significant work done in the model.
- Workset Management becomes more important. If you have sloppy users, this becomes a babysitting effort until they learn.
Exporting takes a bit more time for the entire building. With the increased 3D views, each view needs to be exported separately with OOTB Revit.
- This could potentially be automated through Imaginit’s Clarity
- Or a plugin can be used to automate the process *WINK* to Case Inc.
It takes more forethought. As you can tell from this post, It does require some trial and error to get it right.
In the end, I found this to be an eye-opening experience. One, I have never done a navis model during programming. Most of the time it is a mashup of files coming together from different firms with different formats and naming conventions. Having this much control over the structure at the beginning has made me rethink my strategies for down the road. Two, little tweaks in structure can really streamline the construction of the navis model. Often, the navis model is thrown together hours before a coordination meeting and is poorly structured and horrible to work with. This method really makes me look forward to the design phase and seeing how far this organization can really go.
Hope this has inspired you to take a look at your Navis model in a different way.