Federated Central file -> Everything else (no nested links)
Next challenge: how can we quickly promote those nested links into our federated model? Well, we currently have the module files populated, so how can we leverage those positions to promote the nested links?
Promoting Nested Links
It is a bit hacky, but here is how I went about it. For each module file:
Create an empty proxy file (New Revit project, no template)
Open the Module file and resolve all link paths (so they are loaded)
Set links to Attachment
Copy / paste the link Instances from the module file (Level 0 or Base Level) into the empty file (Level 1, default level). You can use Dynamo graph above.
Save the new proxy file as ‘ModuleContainer’ or similar. We know have a file that only has link instances in it.
Open a detached copy of the Federated Central file (you can save as temporary copy if you like)
Select the current Module file,
replace with the ModuleContainer you created. Once you have done all the modules, you are ready for binding as described below.
After populating the detached Federated Central file, we just need to Bind and then Copy / Paste the free instances:
After load, Bind the ModuleContainer files to the detached Federated Central model
To do this, right-click on the file in Revit Links in Project Browser
Select All Instances – In Entire Project
In the Ribbon, click Bind Link
Untick Attached Details, Levels, Grids
Click Remove Link when prompted
Your nested links are now promoted!
Optional: Ungroup all of those bound free instances (select all from Project Browser, Ungroup in Ribbon)
Open the real Federated Central file
Copy / paste the populated free instances from the detached Federated Model to the real Federated Model. Use the Dynamo script to collect them.
Tip: Paste into a closed workset for better performance.
Close the detached one, and sync the real one
The only thing we technically ‘broke’ or lost in this process is the module link->nested link relationship. So if someone decides to move one of the nested links in the module link, obviously that won’t replicate into the Federated Central file.
Hope this helps some of you out there building or dealing with large federated models.
A federated Revit model is a model containing many Revit links, and they can be quite slow to work with. There are a few steps you can take to speed things up, and one of them is creating a set of fast view types and a related view template.
Make a View Template called “No Model” and untick all the Model categories in that Template
Make a set of View Types called “Fast Plan“, “Fast Section” and so on
Set the View Template for those Types to the “No Model” template you created
Now, when cutting sections or making new floor plans using these ‘fast’ view types, the view will generate quickly without any model elements. Then, you can decide if you want to switch view templates / types to something more useful for coordination or documentation.
It can be pretty hard to track what is visible in a big federated model, and even harder to figure out when something has been changed or updated. Until now…
Check this little node out:
This gets five pieces of information and writes each of them to a View instance parameter. Currently, it works in the context of the currently active view in Revit. The information acquired is as follows:
current date / time
worksets currently opened
RVT links that are visible in the view
the file sizes of those links
the date modified for those links
The ‘list items’ are converted to a string with line breaks. Then when it is referenced in a Label in a View Title family (on the far right of image above), it basically shows up as a list.
Future applications of this can easily include reading the link status from the view parameter (by converting the string back to a list), comparing it to current link status, and then immediately showing what models have been updated and need to be reloaded…
There is no immediately easy way to override the colour of an entire Revit Link. Of course, you can set up a View Template and override all of the individual subcategories, but that can get time consuming when working with many links…
Worksharing Display Mode gives us a quick way of visualising Worksets. What if we put each Revit Link on its own Workset? Then if we set Worksharing Display Mode to Worksets, these Links are overridden with the Workset colours selected in the dialog:
Unfortunately, the Worksharing Display Mode setting is a temporary override (notice the border around the view?), and it will be switched off when we close and open the file. However, the colour choices will be retained. Is there a way we can quickly ‘turn on’ the Worksharing Display Mode for all views in the document? Perhaps this could be done just prior to printing, or at the start of an editing session?
Enter… you guessed it… Dynamo.
I made a node to Enumerate Worksharing Display Modes available, and another one to Set Worksharing Display Mode for View. Finally, I adapted the archi-lab Get All Views node into a List All Views node. Now, we can set them in one click:
And a Screencast:
Each time you print, you will be prompted to “Leave the mode on and print…“, but the colour override will print fine 🙂
Update: Colours will transfer using Transfer Project Standards, as per: Transfer Project Standards
If you populate a project with the desired worksets, usernames, and colors you can automatically transfer most of this data over to another project. Under Manage > Transfer Project Standards, there is a new option for Worksharing Display Settings.
Keep in mind this will not transfer over workset names from one project to another.
It will however transfer over workset colors, should the same name workset appear in both projects.
So, maybe its not Glue… with the benefit of current knowledge, maybe its Project Skyscraper, or some combination of these. But the External Reference possibility starts to make some of these things truly achievable. Watch this space!