Revit has long understood the difference between a DWG having an attached or overlay external reference (Xref). It uses the same logic for its own linking behavior for RVT files. Recently a client began reporting seeing DWG files including Xref layers in Object Styles and Visibility/Graphics even though the DWG has only an overlay Xref. Revit seems to be converting the overlay Xref to a block element and including it and all the layers in the process.
We noticed it happening first with projects hosted on BIM360. That led me to consider it was because this firm isn't using Autodesk Desktop Connector. Not too surprising considering Autodesk recommends using it for linked DWG support on BIM360.
That's irrelevant now that I've reproduced it on a project file based on a stock template, doesn't use worksets and the all files are on a single PC. It's related to how Revit is reloading the linked DWG when a new session of Revit is opened.
It seems to matter that it is a new session of Revit, opening the project again, and to a lesser degree if there are changes in the DWG file. Any of those conditions seems to be enough to find an overlay Xref(s) showing up but reporting as a block element with Query. It is pretty easy to reproduce now that I've done it a few times.
This is the mockup DWG files.
This is the result of linking the file into a Revit project.
This is what happens after opening Revit and the project again.
This is what Revit's Query feature reports when selecting a line that belongs to the overlay Xref in the linked DWG.
It also occurred to me that it could happen if the host file's Xref was originally attached, when it was linked to Revit and changed afterward. Testing didn't support that theory. The example above is based on a xref that was placed as an overlay from the start, not changed to overlay. It also occurred to me that it might be related to large coordinate values. Civil files are linked here primarily. To rule that out, the mock up I show above is at the WCS origin and linked origin to origin.
This particular firm uses Civil 3D/AutoCAD for their civil and landscape disciplines so eliminating DWG files isn't in their future. This bug is annoying AND increasing the time required to prepare projects for plotting and publishing.
Assuming this isn't being caused by some aspect of this firm's EyeTee implementation (PC configuration and/or security measures) I'd love to hear some corroboration.
We noticed it happening first with projects hosted on BIM360. That led me to consider it was because this firm isn't using Autodesk Desktop Connector. Not too surprising considering Autodesk recommends using it for linked DWG support on BIM360.
That's irrelevant now that I've reproduced it on a project file based on a stock template, doesn't use worksets and the all files are on a single PC. It's related to how Revit is reloading the linked DWG when a new session of Revit is opened.
It seems to matter that it is a new session of Revit, opening the project again, and to a lesser degree if there are changes in the DWG file. Any of those conditions seems to be enough to find an overlay Xref(s) showing up but reporting as a block element with Query. It is pretty easy to reproduce now that I've done it a few times.
- Start a new project
- Link a DWG with an Xref (overlay)
- Save the project > close it and the Revit session
- Open Revit again
- Open project (xref is now visible)
- When the project is opened and the linked DWG has changes it will load the xref too.
- If after opening the Revit project the file looks correct using Reload From will display the xref afterward.
This is the mockup DWG files.
This is the result of linking the file into a Revit project.
This is what happens after opening Revit and the project again.
This is what Revit's Query feature reports when selecting a line that belongs to the overlay Xref in the linked DWG.
It also occurred to me that it could happen if the host file's Xref was originally attached, when it was linked to Revit and changed afterward. Testing didn't support that theory. The example above is based on a xref that was placed as an overlay from the start, not changed to overlay. It also occurred to me that it might be related to large coordinate values. Civil files are linked here primarily. To rule that out, the mock up I show above is at the WCS origin and linked origin to origin.
This particular firm uses Civil 3D/AutoCAD for their civil and landscape disciplines so eliminating DWG files isn't in their future. This bug is annoying AND increasing the time required to prepare projects for plotting and publishing.
Assuming this isn't being caused by some aspect of this firm's EyeTee implementation (PC configuration and/or security measures) I'd love to hear some corroboration.
4 comments:
I just tested this in version 2021, and did not encounter this bug. Overlay dwg links do not appear, even after closing and opening, but Attach dwg links do appear.
OOF disregard that previous comment. I ignored the 'Revit session' part. It's still an issue.
Thanks for checking it out. Yes it is that new session...or just another user working on the file that triggers "it".
Our "solution" is to assign all Xrefs (in AutoCAD/Civil 3D) to unique layers and turn those layers off in Revit (via View Templates usually). This way the extra layers of the xrefs do not show up even though Revit is technically ready and willing to show them.
Hey Steve, thanks for sharing this, very helpful.
Do you know if this is still an issue in Revit 2023.1?
Post a Comment