Bridge the Gap: Automating Navisworks Clash Detection in Revit with Dynamo

Clash detection between Navisworks and Revit is a standard step in BIM coordination, but the workflow often breaks down once the clash report is generated.

Teams end up manually searching for clashes using coordinates or Element IDs, switching between tools, cutting sections, and guessing locations. This slows coordination cycles and introduces avoidable errors.

This guide shows how to automate Navisworks clash visualization directly inside Revit using Dynamo and XML data, so clashes become actionable elements in the model instead of static report entries.

The Core Problem: The Coordination “Wall”

The traditional “Navisworks on one screen, Revit on the other” workflow is a bottleneck. Navigating back and forth to find element IDs, cutting sections, and hunting for grid intersections manually is a waste of skilled engineering time.

Coordination usually hits a wall when the Navisworks Clash Report (.xml) is generated. The data exists, but it isn’t “live” in Revit. Designers spend hours manually locating clashes based on coordinates or Element IDs.

This becomes critical on:

  • Large MEP coordination projects
  • Multi-discipline BIM environments
  • High-frequency clash review cycles

Every clash remains disconnected from the model environment where it actually needs to be resolved.

The Solution: Automated Clash Orbs

The most effective way to handle this is by creating a custom Dynamo script that reads the Navisworks XML export and places a “Clash Orb” (a transparent sphere family) at the exact X, Y, Z coordinates of each interference.

Instead of interpreting a report, teams interact directly with clash locations inside Revit.

How to Import Navisworks Clash Results into Revit with Dynamo

1. The Setup

Navisworks

Run your clash tests as usual. Export the results using the XML format.

This file contains:

  • Point3D coordinates
  • Element IDs / Entity Handles
  • Clash names and grouping data

Important:

Navisworks export coordinates depend on settings under:

  • File Readers → Revit → Coordinates

You must ensure this matches your Revit setup:

  • Internal Coordinates
  • or Shared Coordinates

Mismatch here is the main reason clashes appear in the wrong location.

Revit Family

Create a simple Generic Model family consisting of a sphere with a transparent material.

Add shared parameters:

  • Clash Name
  • Element ID
  • Status

Best practice:

  • Keep geometry low-poly
  • Assign to a dedicated “Coordination” workset

2. The Dynamo Logic

The script performs three primary functions:

XML Parsing

It parses the Navisworks XML to extract:

  • Point3D coordinates
  • Clash names
  • Element identifiers

Coordinate Mapping (Critical Step)

Navisworks and Revit do not always operate in the same coordinate system.

Instead of relying only on manual vector shifts, use a proper transformation approach:

  • Validate whether XML coordinates are Internal or Shared
  • Ensure Dynamo operates in the same system
  • If needed, apply CoordinateSystem.Transform rather than only using Vector.ByCoordinates

Vector shifts can work for simple offsets, but they break when:

  • rotation is involved
  • project base vs survey discrepancies exist

This is where most implementations fail.

Family Placement

The script triggers FamilyInstance.ByPoint to place the “Clash Orb” at each clash location.

3. Pro-Tips for Implementation

Lacing Matters (Avoid This Common Mistake)

When using List.GetItemAtIndex, do NOT default to Cross Product.

  • Cross Product will multiply lists (e.g., 500 × 500 = 250,000 placements) and can crash Revit
  • For clash mapping, you need a 1:1 relationship

Use:

  • Longest Lacing (recommended)
  • or Shortest Lacing

This ensures each coordinate matches the correct clash name and ID.

Data Enrichment

Don’t just place a sphere. Use Element.SetParameterByName to push:

  • Clash Name (e.g., “Clash 1”)
  • Element IDs
  • Status values

This turns each orb into a usable coordination object.

Live Schedules

Once the spheres are in Revit, create a Generic Model Schedule.

You can:

  • Select a clash from the schedule
  • Use “Highlight in Model”
  • Navigate directly in 3D

This replaces manual searching.

Advanced Implementation: Making the Workflow Production-Ready

Handling Duplicate Clashes

Navisworks XML often includes:

  • Duplicate entries
  • Grouped clashes sharing coordinates

Solution:

  • Filter by unique (coordinate + element ID) combinations
  • Clean the dataset before placement

Managing Iterations Without Breaking the Model

Running coordination weekly?

Avoid deleting everything each time.

Instead:

  • Assign a unique clash ID
  • Compare new XML vs existing elements
  • Update only new or unresolved clashes

Without this, models get cluttered fast.

Dealing with Misaligned Coordinates

Ensure Shared Coordinates are properly configured before export.

If transformation is required:

  • Prefer CoordinateSystem.Transform
  • Use Vector.ByCoordinates only for simple offsets

Incorrect handling leads to misplaced clash geometry.

Dynamo vs Other Clash Coordination Methods

Dynamo Workflow

  • Full control inside Revit
  • Clash data becomes model elements
  • Customizable and scalable
  • No extra licensing
  • Fast navigation
  • No model modification
  • Still requires tool switching
  • Limited automation
  • Faster setup
  • Preconfigured workflows
  • Less flexibility
  • Additional cost

Why This Works

Moving clash data into Revit turns a report into a live coordination dataset.

You can:

  • Track progress visually
  • Remove resolved clashes
  • Keep remaining issues visible

This improves:

  • Coordination meetings
  • Decision-making speed
  • Team alignment

On large projects, this approach can reduce clash resolution time by 50–80%.

Common Mistakes to Avoid

  • Using Cross Product lacing incorrectly
  • Ignoring coordinate system mismatches
  • Relying only on vector offsets
  • Not cleaning previous clash elements
  • Using high-detail families
  • Skipping parameter mapping

Quick Workflow Summary

  1. Run clash detection in Navisworks
  2. Export XML
  3. Parse XML in Dynamo
  4. Validate coordinate system
  5. Apply coordinate transformation if needed
  6. Place clash spheres in Revit
  7. Push metadata into parameters
  8. Manage clashes via schedules

FAQ

How do I handle coordinates if Revit and Navisworks aren’t perfectly aligned?

Ensure Navisworks export settings match Revit:

  • Internal vs Shared Coordinates

If transformation is required:

  • Use CoordinateSystem.Transform
  • Use Vector.ByCoordinates only for simple offsets

Can I use this for point cloud clashes?

Directly, no. Navisworks can detect clashes with point clouds, but Revit families cannot interpret point cloud density via Dynamo.

Use Navisworks Switchback instead.

What happens if I run the script twice?

Without cleanup logic, Dynamo will duplicate all spheres.

Best practice:

  • Use Select All Elements of Type
  • Then Element.Delete before placement

Do these spheres affect model performance?

Yes, on large datasets.

Mitigation:

  • Use low-poly geometry
  • Place in a Coordination workset
  • Control visibility

How do I get the Element ID from Navisworks into the sphere?

The XML contains Entity Handle / Element ID.

Map it to a text parameter and use Select by ID in Revit.

Can this workflow be used in a BIM execution plan (BEP)?

Yes. It integrates well into:

  • Weekly coordination cycles
  • Discipline tracking
  • Structured BIM processes

Can I extend this workflow further?

Yes:

  • Color-code clashes by discipline
  • Link to issue tracking systems
  • Automate status updates
  • Export reports from Revit

Similar Posts