Models change rapidly at various stages of the project, and it can be useful to review model status between different revisions of the models.  What changed? Why?

There are a number of Model Compare tools out there, Navisworks has one built-in and there are addins for Revit. But what if you just want a quick visual check?

Here is one method using Revizto…

Using Two Instances of Revizto and the Issue Tracker to Compare Models

  1. Open two instances of Revizto and put them side by side on your screen (large monitor will help)
  2. On one of the instances, go to Project -> Revisions and open a previous version of your model

  3. You can now navigate between two different versions in these two instances
  4. The issue tracker data is always up to date, so you can use the Issue Tracker to co-locate yourself in each file and check the differences. Just click on the same issue in the Issue Tracker, and then click on 3D to visually compare the models. Obviously, you can also enter data and snapshots into the Issue Tracker as per usual, perhaps to comment on why a particular model changed between versions.

Another Idea…

Essentially, this idea was to launch two instances of Revizto and use the Camera Share tool to navigate the same model between them.  It was a bit more involved, and it requires you to have access to two different login accounts for Revizto, and two different login accounts for the current machine, and Revizto is installed ‘For Everybody’.

  1. Ensure you have psexec available
  2. Make a CMD with this text:
     psexec -u OtherWindowsUsername -p OtherWindowsUserPassword -d -i "C:\Program Files\Vizerra LLC\Revizto4\Viewer\Revizto.exe" /language ENU

    (needless to say that you should be careful to protect the password above)

  3. Open Revizto normally and login
  4. Run this CMD file, and in the new instance of Revizto you can login to a different Revizto account
  5. Open the same Revizto project in each
  6. You can now use the Camera Share tool to ‘drive’ both instances simultaneously. Pretty cool!
  7. In one of the instances, open a previous Revision of the model
  8. *This is where the idea fell down, as Camera Share no longer offered to share camera between two different versions of the model :)*  Evidently, it won’t let you navigate non-similar models at the same time.

I re-tooled the steps above from my previous post about logging into multiple Autodesk logins at the same time:

How to Workaround A360 SSO issues by Running another Instance of Revit in Same Windows Session as different User

Interesting little release by Dimitar Venkov on Github a few months ago. It is essentially a Python shell for Navisworks 2016. You install by unzipping as per instructions below. You may have heard about RevitPythonShell, but obviously this one is for Navis.

To install, simply extract the zip archive in the below folder:

%APPDATA%\Autodesk Navisworks Manage 2016\Plugins

Downloads

You can read more about the features at the main page here.

  • interactive IronPython interpreter for exploring the API
    • with syntax highlighting and autocompletion (in the console only)
    • based on the IronLab project
  • batteries included! (Python standard library is bundled as a resource in the RpsRuntime.dll)
  • full access to the .NET framework and the Navis API
  • configurable “environment” variables that can be used in your scripts
  • save “external scripts” for reuse and start collecting your awesome hacks!
  • run scripts at Navisworks startup

And some example/s are in a GitHub folder:

I’ve had a mixed experience using the Nvidia GTX 980 card in Navisworks and Revit, but I have one particular tip that helped in Navisworks 2017:
Turn OFF CPU Occlusion Culling

My CPU is an i7-6700K that I generally OC to 4ghz. But obviously there is some slowdown when both of the Occlusion Culling boxes are ticked.

Aside from the usual tips of using ‘Guarantee Frame Rate’, Automatic Clipping Planes, and playing around with the File Options – Frame Rate, I found that turning off CPU Occlusion Culling and leaving GPU Occlusion Culling on made a real difference for the better.

Navisworks works really well with Point Clouds, particularly in association with Recap. It will usually create ‘voxels’ – groups of points that you can hide or change colour or use in other Navisworks workflows.

However, sometimes the ‘point size’ seems too fine. To modify this, just open up Navisworks Options to Interface – Display, and change the Primitive size for Points to something that looks better. You can choose any size from 1-9.

Also, there are additional settings under File Readers – ReCap:

You can set an ‘interactive point size’ here, which is going to override the point display when you are zooming around or navigating the model.

Parts allow some extremely powerful workflows in Revit. Did you know that you can take an in-place family, and when you Divide Parts, Revit will make an individual Part for each geometric element?

For example, let’s say you have a big sweep that represents a large part of a Building, and that Sweep is inside an in-place Generic Model family in the project.

Firstly, use some Voids to cut the sweep into the sections or pieces that you want…

and then select that Generic Model Family and click Create Parts. You will get a Part for each geometric piece, like this:

Then, if you edit the underlying Family and divide it with more Voids, Revit will automatically create and update the Part elements as needed. Very cool.

From here, you can export those Parts to Navisworks for animation or sequencing, if you so desire.

Recently I had an issue sharing colour overrides from Navisworks to BIM 360 Glue. This has been ok for a while, but something broke. After some investigation, it turns out that one of the sub-Models in the Glue merged model was causing the problem.

I typically convert IFCs using the Link method, which results in DirectShape objects. It seems that one of the Architectural files that I converted this way from ArchiCAD to Revit and then to BIM 360 Glue was stopping the colours from getting baked into the BIM 360 Shared View.

To workaround this issue:

  1. Determine what problem model/s you have (possibly those converted from IFC)
  2. Open your Merged Model in Navisworks for BIM360
  3. Hide these problem models in Navisworks scene
  4. Run Appearance Profiler or otherwise apply colour overrides
  5. In the BIM 360 Shared Views pane, click New to make a new Shared View on BIM 360 Glue with the colours ‘baked in’
  6. Go to Glue desktop app and confirm the colours are working
  7. Then, Unhide the problem model here…
  8. And then make a new view in the desktop app
  9. This new view should have all models you want showing, and the colour overrides working ok.

On a related note, you may have seen this warning:

 
View in model is still processing and some items may not be overridden

It seems that this might put your Glue merged model in a dirty state? Try deleting all views with this message before trying to create Shared Views from Navisworks with colour overrides.

If you have a Navisworks crashing or Navisworks not starting up problem, you might try resetting Navisworks settings.

Here’s how:

  1. Open Windows Explorer
  2. Type %appdata% in the address bar
  3. Rename the relevant Navisworks folder here with a .bak extension
  4. Start Navisworks

Note: You can actually get to the options from the start menu, even if Navis won’t launch…

 

There are other places that Navis may stash some settings. You may also want to check out:
https://forums.autodesk.com/t5/navisworks-forum/apply-simulate-manage-default-settings-automatically/td-p/2778014

I have posted some other methods before…
Batch Convert DWF to Revit using Navisworks
How to Convert a DWF to Editable Format, or How to Export from Navisworks and Keep Modelling in BIM
Export Geometry from Navisworks into Revit (and back again) using only AutoCAD

… but here is one going via 3dsMax:

  • Export FBX from Navisworks
  • Import to 3dsMax
  • Export SAT
  • Import to Revit

via

http://www.revitforum.org/architecture-general-revit-questions/7636-anyone-ever-import-navisworks-file-intorevit.html#post63006

Also, keep in mind that newer versions of AutoCAD can directly link NWC or NWD Navisworks files using CMATTACH (Coordination Model Attach).

Navisworks is pretty amazing at handling a huge set of properties across a large amount of elements. However, sometimes it can be hard to diagnose why a particular parameter, such as a Shared Parameter, is not displaying or grouping in a way that you might expect.

To figure out what is going on, go into Navisworks Options – Interface – Developer and tick the two boxes:
Show Internal Properties
Show Property Internal Names

Now, when you use the Properties palette you will see additional information in brackets, which essentially amounts to the Navisworks ‘internal parameter name’ for a given piece of data. Pretty cool!

Thanks for this tip goes to Jason Howden, from RTV Tools, a Platinum sponsor here at What Revit Wants.

props.png

Related forum post:
https://forums.autodesk.com/t5/navisworks-general-discussion/navisworks-manage-2015-amp-revit-project-parameter-problem/m-p/5672998#M9579

 

XML files are everywhere. And in the BIM world, we have to deal with a range of different xml file schemas, such as BCF, Navisworks Clash Reports and Viewpoints, and so forth. Hiding inside these XMLs there is some very useful information. For example, BCF files often have Element IDs in the viewpoint.bcfv component, and Navisworks XML files often have point XYZ values. Can we easily get access to this information for use in Dynamo, and then in Revit?

Yes, we can! There were one or two ways to do this in Dynamo before, but here is my take on it…

Dynamo ships with IronPython, which in turn ships with an XML handler called ElementTree. I have created some basic nodes that give us access to ElementTree functions in Dynamo. Along the way, I learnt a bit about encoding and character sets. It turns out that Navisworks often inserts tricky characters into the XML (like the diameter symbol), so as a workaround (for now) I do a string encoding roundtrip to get rid of these problematic characters. In the same node, I create the ElementTree object: this is a special object that essentially represents structured information about the XML data. The initial import looks like this:

Once we have this ElementTree object in hand, we can start to do some interesting things, like:
Iterate through tree to get individual XML elements

iterate.png

and Show a hierarchical representation:

With the individual elements, we can Get Attribute names and values, and the Get the children of those elements:

Obviously, you can immediately do some nice lookups against these lists in Dynamo, depending what information you want. However, on large XMLs this can be quite slow. Happily, ElementTree provides some basic XPATH support, which looks a bit like this:

With the XPATH support and an understanding of the xml hierarchy, I have created a node to do XPATH calls straight to the ElementTree object:

Now that we can ‘snip’ out useful information from the XML, we can do interesting things with it, like make some points:

When it comes to BCF, its a little bit more challenging. I haven’t figured out how to unpack the bcfzip directly to memory (yet), so we have do that manual step first. Once we have a ‘folder’ from the BCFZIP, we can get the bcfv files from inside it and then get information from them, like this:

So, in the latest Bakery package are the nodes needed to read a variety of XML files, get information from them, and do some useful things with that information. It was a learning experience for me, and I hope its useful to you 🙂

version.png