Multiple files not aligned in Navisworks

[rsloyer]

I know this is an old thread, but I'm having the same problem and the "transform" isn't fixing it.

I bring the two files, one duct one condenser piping, into Revit. I dimension the x and y difference between the two. I append the condenser piping model to the ductwork, then right click on it in the selection tree and type in those same dimensions in the x and y, but negative. Is this the right procedure? It's not giving me the right alignment.

[mitch.cornelius]

Make sure you check your CAD units to your NavisWorks units.

[tonyisenhoff]

I've had this happen a few times. My solution is this:

1. In Revit: Link the consultants model into my architectural model and be sure things line up. (we normally have it linked already, so this really isn't an extra step)
2. Publish the coordinates to the consultants model.
3. Open the consultants model and create a new .NWC
4. It updates in Navisworks and lines up properly

I've done this a few times and it works every time.

[L Wood]

Navisworks user for two years... I have been advocating my teams model based on a common internal origin point (insert origin to origin)... which has worked great thus far.

While testing out a workflow between Civil 3d+Revit which included sharing/acquiring coordinates... I decided to export NWC files and archive a Revit file before I executed a command in Revit, just to verify the results in Navisworks and Revit.

The result was very interesting:

All the NWC files with “shared coordinates” consistently imported into Navisworks the same location, away from the files with no shared coordinates. I was expecting the files to import origin to origin as I was under the impression Navisworks only recognizes Revit’s internal origin (not project origin or shared coordinates).

I decided to back track with the incremental Revit files I had saved along the way, linking them together “origin to origin”, found they all coordinated perfectly (completely on top of each other). This was totally different from the result in Navisworks… leading me to the question, what the hell does Navisworks really use to ID the origin point of a file?

Going back to the aggregated Navis file, I couldn’t put my finger on the source of the distance between the non-shared and shared coordinate files. I took a spot coordinate dimension from the non-shared and compared that with the shared-coordinate file in Revit and found no correlation to the distance of the files in Navisworks.

Can anyone explain what the secret key is to shared coordinates in Revit and the import location in Navisworks? Is anyone from Autodesk able to explain?


Thanks in advance for your time,
Laura Wood

[amixam]

When you exported our of Revit, did you have shared coordinates checked in the options? This needs to be set, otherwise your files will export as you've experienced.

Cheers

[david.kingham]

Has this always happened or only in 2010? Before 2010 navis only cared about the hard coded origin in Revit, but now you can select shared coordinates (although I haven't had the chance to use it yet because everyone is using the same origin)

[Tyveka]

I believe the shared coordinates export/import lining up is new to 2010.
What's interesting - I've had issues with shared coordinates in AutoCAD files (since not all of our consultants can use Revit). Those shared coordinates create named UCS views which Navisworks will NOT read, despite them being active at the time. So lots of interesting ways to get project to line up...
The best method we've found so far - define a common point and line up to it in Navisworks and the other programs you're using.

[L Wood]

Brilliant amixam... it looks like 2010 Navis does have a new feature to export to shared coordinates... and the exporter does have shared coordinates as it's default setting.

After sleuthing on the www... found this helpful post on the bim x blog.
http://bimx.blogspot.com/2009/03/my-...orks-2010.html


I'm wondering where Autodesk publishes a list of new features for it's products. That easter egg could really trip a team up in the middle of a project.