Revit plugins updates and new features

As usual during this time of the year, I published the new version of my plugins for Revit.


The big improvement this year is the ability to align any type of elements, annotations or tags. I must thank Deyan Nenov and his large contribution to the source code for this new feature.

From now on, you can select any kind of element and align or distribute them evenly. This feature use the bounding box of the element in the view as a reference.

Align or distribute all elements

The Align command is still view-dependent, so using it in section view or in a plan view will not have the same effect on the overall position of a given element. A word of caution however, the align function can be unreliable in a 3D view.

View-dependent align functions

Of course, you can still use it to align or distribute your tags and annotations, and it even works with viewports:

Align viewports

Along with these improvement, Align now fully support Area tags, and a few bugs have been eliminated. You can now use Align even if on tag without a leader, and multi-leader text are now fully supported, and some selection subtlety have been introduced.

Align tags and texts

I haven’t tested it with all categories, if you find something weird, please let me know, I would be happy to fix it.

You can find this new version on the Autodesk App Store.

Room Finishing

Along with the support for Revit 2018, I corrected an issue where a skirting board was created even if the room was not bound by a wall. From now on, Room Finishing will not create a skirting board along room bounding lines.

Support room with room boundary lines

Room Finishing is also available on the App Store.

Time Stamper

The Time Stamper plugin got a few improvements this year along with the usual bug smashing.

You can now choose between applying your time stamp to every element, or just the one visible in the view. This will give you the ability to filter on which element you want to apply a stamp.

You can also choose to keep or override an existing value, this should help you keep the history of a given element.

A few bugs where corrected, making the creation of the four shared parameters far more reliable. Groups are now supported.

Support for groups

Time Stamper is now available here.

These new versions are now available on the Autodesk App Store. Don’t hesitate to report any issue you might find in them or ask for improvement.

These plugins are open source, you can find the source code here, here and here. Feel free to use it on your own project or contribute to these projects.

Building a Forge Web Viewer

Web-based “BIM” solutions are the last big trend, and Autodesk is among the most advanced player in this area with their API offering called Forge.

Autodesk Forge is a product from Autodesk that don’t come with a user interface. Instead, it is designed to be used through other software, and especially web-based solutions. Autodesk Forge is also the technology behind most of the web-based product of Autodesk, like BIM 360 Team, Docs or the A360 Online File Viewer.

The community around these products is growing, and new resources and samples are published on an almost daily basis.

Among them, Augusto Gonzales recently wrote a comprehensive tutorial to build a small web viewer using Autodesk Forge and ASP.NET. Being more of a .NET programmer, I took on this opportunity to learn more about this new product and build my own web-based Forge viewer.

I start by creating an ASP.NET Core MVC Web Application with this tutorial. ASP.NET Core being a web framework developed by Microsoft, you can use your C# skills to “easily” build web application.

I follow the detailed explanations from Augusto Gonzales to send my model to the Autodesk server for conversion, get an GUID back and use it to display my model in the Forge viewer. The explication on the blog are straightforward, and I won’t delve into it. I just had to made some few changes since I am using a different version of the ASP.NET Core framework.

Using technologies from Microsoft, it is easy to publish my application on Azure, the Microsoft cloud hosting solution.

I called the end-result Termite, and it is available here.

The Termite Web Viewer

By default, you see a model of my neighborhood from my last post, but you can also upload your own files. A word of caution, uploading and translating a large model can take quite some time, do not close the windows until your model is displayed on the screen.

I also add some features to the viewer. You can lock the rotation of the view by clicking on the lock icon. I also put in place a very basic section tool. To use the section, click on “Add a section” and select a face in the model to create your section.

Viewer Extensions

These features are built as extension of the Autodesk Forge Viewer, are written in JavaScript and run in the browser of the end user.

The source code is available on GitHub. Seasoned web developer will probably find a lot to correct in my application, but I hope to improve with practice

I still have a lot to learn in this area, so you might expect some other web app in the next few weeks.

Align Tag Update

It is this time of the year again, and I have finally take the time to update Align on the App Store for the new version of Revit.

However, there is more in this than a simple version update, and this new release is packed with improvement, both small and large.

The main change reside in the alignment method. In the previous version of Align Tag, I was using the center point of a given tag as a reference to align tag (either left or right). To improve on the alignment of tags of various sizes, I now use the bounding box of the tag.


Tags will now properly align themselves along their right or left side, regardless of their size or origin point.


However, if you want something similar to the older version, you can use the new Align Center and Align Midlle commands, which will use the center of the tag as a reference.

This new alignment method is more in line with what can be found on solutions like PowerPoint, or Adobe Illustrator, and will allows you to neatly arrange your tag whatever their size or origin point.

Another important improvement is the long awaited support for Text. You can now align Text along with Tag, using the same command.

While I was at it, I also add support for Keynote tag, Room Tag and Space Tag, basically every tag. The Area Tag is still missing, but can be expected for the next version.

However, this support came at a cost, and I have to drop the support for Revit 2015 and prior. So, if you are still using this version, you will have to keep the old Align plugin.

There is also a handful of small UI improvement that I hope will help you.

Aligned tags are now kept selected after running the command so you can align them in another direction right away.

Your Align commands are also one click closer to you! The interface have been artfully arranged in a new tab to keep every icon directly accessible in the ribbon.


Under the hood, I have rewrote a large part of the code to support more types of annotation elements, and I hope to be able to use this new framework for more complex manipulations, including in the Arrange Tags function.

Of course, Align Tag is still open source, the entire code can be found on Bitbucket.

This plug-in is already available on the Autodesk App Store. If you like it, don’t hesitate to write a nice comment or add a few stars, it always means so much to me!

Details Items, subcategories and filled regions

I am currently working with multiple detail items to create a set of views for architectural detailing. These Detail Items must comply with a precise standard for color and line weights, and of course, be consistent all over the model.

To implement these requirements, I define a set of subcategories for these detail items. Let see how it works with these two wood windows details.


These detail items already contain various subcategories, and I can control the color, weight and patterns of their lines in Visibility Overrides. Here Medium Lines are blue and Light Lines are red. Interesting, but not quite enough.


I open these two detail items, go to Object Styles, and create four new subcategories: Wood, Glass, Sealant and Steel. I also remove the previous subcategories. I can now select all lines in the detail item, and assign corresponding subcategories to these lines. Once these detail items are loaded back in the model, the four Detail Item subcategories are visible in the Graphic Overrides window.

I can now control line color, weight and pattern directly in my model, in the Graphic Overrides window for the current view, or in the Object Styles window to apply these colors to every details in the model.


Sadly, there is no corresponding feature for managing filled region. As you can see in the picture above, the wood pattern is still in black.

In order to change pattern or color in a filled region, you have to edit the detail item and change the filled region style in the family. If you want to edit your wood pattern, you have to open every detail items containing wood, and change the pattern in the family.

To fix this, and be able to edit directly filled region style for every detail item, I create a small piece of code. This function matches model filled region types with those inside the detail item. So if I have a filled region in my Detail Item family with the same name than one in my Revit project, this filled region will take the properties of the one in the project.


After running this function, I end up with nicely matching wood pattern, all set up directly in my Revit project.


As usual, you will find the source code for this solution below, I hope it will help you solve your filled region issues.

public partial class ThisApplication
	public void MatchFilledRegion()
		Document doc = this.ActiveUIDocument.Document;
		//Find all Filled Region Type, and create a dictonary with it
		Dictionary<string,FilledRegionType> modelFilledRegionTypes =
			new FilteredElementCollector(doc).OfClass(typeof(FilledRegionType)).ToElements().Cast<FilledRegionType>().ToDictionary(e => e.Name);
		//Find all loaded families
		IList<Element> elements = new FilteredElementCollector(doc).OfClass(typeof(Family)).ToElements();
		//Get Detail Item category id.
		ElementId detailItemCategoryId = doc.Settings.Categories.get_Item(BuiltInCategory.OST_DetailComponents).Id;

		//Loop on all loaded families
		foreach (Element familyElement in elements) {
			Family family = familyElement as Family;
			//Exit the families loop if it isn't a Detail Item Familly
			if (family.FamilyCategory.Id != detailItemCategoryId) continue;

			//Open the family
			Document familyDoc = doc.EditFamily(family);
			string familyPath = Path.Combine(Path.GetTempPath(),family.Name+".rfa");
			bool familyEdited = false;
			//Find all Filled Region Type in the family
			IList<Element> filledRegionTypes = new FilteredElementCollector(familyDoc).OfClass(typeof(FilledRegionType)).ToElements();
			using (Transaction famTx = new Transaction(familyDoc))
				famTx.Start("Edit Filled Region Type");
				//Loop on all Filled Region types in the family
				foreach (Element filledRegionTypeElement in filledRegionTypes)
					FilledRegionType filledRegionType = filledRegionTypeElement as FilledRegionType;
					if (modelFilledRegionTypes.ContainsKey(filledRegionType.Name))
						FilledRegionType refFilledRegion = modelFilledRegionTypes[filledRegionType.Name];
						//Change the color
						if (filledRegionType.Color.Red != refFilledRegion.Color.Red
						    || filledRegionType.Color.Blue != refFilledRegion.Color.Blue
						    || filledRegionType.Color.Green != refFilledRegion.Color.Green)
							filledRegionType.Color = refFilledRegion.Color;
							familyEdited = true;
						//Change the Background
						if (filledRegionType.Background != refFilledRegion.Background)
							filledRegionType.Background = refFilledRegion.Background;
							familyEdited = true;
						//Change line weight
						if (filledRegionType.LineWeight != refFilledRegion.LineWeight)
							filledRegionType.LineWeight = refFilledRegion.LineWeight;
							familyEdited = true;
			if (familyEdited)
				familyDoc.LoadFamily(doc, new FamilyOption());
				familyDoc.Close( false );
				familyDoc.Close( false );

public class FamilyOption : IFamilyLoadOptions
	public bool OnFamilyFound(bool familyInUse,out bool overwriteParameterValues)
		overwriteParameterValues = true;
		return true;
	public bool OnSharedFamilyFound(Family sharedFamily,bool familyInUse, out FamilySource source,out bool overwriteParameterValues )
		source = FamilySource.Family;
		overwriteParameterValues = true;
		return true;

Some Thoughts About Rooms and Spaces

A lot of MEP calculations available in Revit needs analytical spaces at some point, and it is crucial to have them properly modeled.

Properly placing these spaces can be a tedious business, especially for large buildings with hundreds of rooms. You can use the Place Space Automatically function, but it can create spaces in undesired places, and does not necessarily match the architectural rooms.

Furthermore, superposing of a space upon an existing architectural room only retrieves the name and the number of the corresponding room, and falls short for any other property we could want to add to our MEP space.

One of the solutions for creating MEP spaces is to match rooms created in the linked architectural model. To do so, I wrote a small application for creating a space for each room defined in a linked model.

This application loops on every linked instance, searching for rooms, and uses these rooms to create the corresponding space, retrieving in the process a handful of parameters, like name, number, and most critically, Limit Offset.

You can find here a little ScreenCast showing how it works. The entire source code is available below.

While working on it, I also found some interesting property : Computation Height. This is a level property, and it allows to define the height used to define boundaries on this level.

Let’s create three rooms on a given level:


But if we add some variation on the floor level, the room disappears with the following warning:Warning


By default, these rooms are calculated at the level elevation. Every wall at “0 m” above the level will be used as a room boundary.

The Computation Height properties allows us to change the elevation where we calculate the room. In our example, we change the Computation Height of the Level 1 to 1 meter, and the room fit nicely between its boundaries.


Of course, this is also true for Spaces.

public void RoomToSpace()
	Document activeDocument = this.ActiveUIDocument.Document;
	//Get All linked instance
	FilteredElementCollector collector = new FilteredElementCollector(activeDocument);
	List<RevitLinkInstance> linkInstances = collector.OfCategory(BuiltInCategory.OST_RvtLinks).WhereElementIsNotElementType().ToElements().Cast<RevitLinkInstance>().ToList();
	//Get all levels
	collector = new FilteredElementCollector(activeDocument);
	List<Level> levels = collector.OfCategory(BuiltInCategory.OST_Levels).WhereElementIsNotElementType().ToElements().Cast<Level>().ToList();
	using (Transaction tx = new Transaction(activeDocument)) {
tx.Start("Create Spaces");

//Loop on all linked instance
foreach (RevitLinkInstance linkInstance in linkInstances) {
	//Get linked document
	Document linkedDocument = linkInstance.GetLinkDocument();
	//Get linked instance position
	Transform t = linkInstance.GetTotalTransform();
	//Get rooms in the linkedDocument
	collector = new FilteredElementCollector(linkedDocument);
	List<Room> linkedRooms = collector.OfCategory(BuiltInCategory.OST_Rooms).ToElements().Cast<Room>().ToList();
	//Create a space for each room
	foreach (Room room in linkedRooms) {
LocationPoint locationPoint = room.Location as LocationPoint;
XYZ roomLocationPoint = locationPoint.Point;
roomLocationPoint = t.OfPoint(roomLocationPoint);

if (roomLocationPoint != null)
	Level level = GetNearestLevel(roomLocationPoint,levels);
	UV uv = new UV(roomLocationPoint.X, roomLocationPoint.Y);
	Space space = activeDocument.Create.NewSpace(level,uv);
	space.Number = room.Number;
	space.Name = room.Name;

	Parameter limitOffset = space.get_Parameter(BuiltInParameter.ROOM_UPPER_OFFSET);


private Level GetNearestLevel(XYZ point,List<Level> levels)
	Level nearestLevel = levels.FirstOrDefault();
	double delta = Math.Abs(nearestLevel.ProjectElevation - point.Z);
	foreach (Level currentLevel in levels) {
if (Math.Abs(currentLevel.ProjectElevation - point.Z) < delta) {
	nearestLevel = currentLevel;
	delta = Math.Abs(currentLevel.ProjectElevation - point.Z);
	return nearestLevel;

Model Timestamp

As we receive models from subcontractors or partners, we need to integrate them in a coordination model.

The coordination model files structure look like this.filestructure

In the coordination model, we use linked views and model specific overrides to fine tune model display. To keep these settings when a linked model is updated, we just override the previous liked file with its new version. This process implies to rename the file each time we receive a new version from a subcontractor. So when we receive a file named with a date or a version, we rename it along some quality control checks.


But we also have to follow which model version we are linking in our coordination model. Renaming files is great to keep the link alive, but we lost the original name in the process.

To keep track of the version of the linked file, I create some kind of timestamp on every object of a given model. This application writes version information on four shared parameters, common to every object.

Once in the coordination model, these shared parameters allows us to know from which version a given element came from.


They can also be used to create filters to highlight the origin of each element in a view.

I also find some very interesting side effects. For example, I create a linked models schedule with a multi-category schedule displaying only the four shared parameters.


My only concern is the performance of such an application. I run it on the Revit MEP example file, and it take 31 seconds, regeneration included. It could easily handle a larger model, but the user will then need some patience as the application run.

You will find below a piece of code I use to write values on every elements of the model. This code does not include any interface, but I hope to be able to publish a packaged version anytime soon.


public void ModelTimeStamp()
	Document doc = this.ActiveUIDocument.Document;
	using (Transaction tx = new Transaction(doc)) {

		tx.Start("Model TimeStamp");

		//Create a list of category
		CategorySet myCategories = CreateCategoryList(doc, this.Application);

		//Retrive all model elements
		FilteredElementCollector collector = new FilteredElementCollector(doc);
		IList<ElementFilter> categoryFilters = new List<ElementFilter>();

		foreach (Category category in myCategories)
			categoryFilters.Add(new ElementCategoryFilter(category.Id));

		ElementFilter filter = new LogicalOrFilter(categoryFilters);

		IList<Element> elementList = collector.WherePasses(filter).WhereElementIsNotElementType().ToElements();

		//Add the value to all element
		if (elementList.Count > 0)
			foreach (Element e in elementList)
				WriteOnParam("Date", e, DateTime.Now.ToShortDateString());
				WriteOnParam("Version", e, "First Release");
				WriteOnParam("FileName", e, "SubContractors Model");
				WriteOnParam("Trade", e, "HVAC");



private void WriteOnParam(string paramName, Element e, string value)
	IList<Parameter> parameters = e.GetParameters(paramName);
	if (parameters.Count != 0)
		Parameter p = parameters.FirstOrDefault();
		if (!p.IsReadOnly)

private CategorySet CreateCategoryList(Document doc, Autodesk.Revit.ApplicationServices.Application app)
	CategorySet myCategorySet = app.Create.NewCategorySet();
	Categories categories = doc.Settings.Categories;

	foreach (Category c in categories)
		if (c.AllowsBoundParameters && c.CategoryType == CategoryType.Model)

	return myCategorySet;

Revit categories and classification systems

Standards for classifying building elements have been around for some times, but building information modeling gives us new perspectives for using them.

There is a handful of these classifications currently in use. The Construction Specifications Institute produce the MasterFormat and UniFormat, used in United States and Canada. The Construction Project Information Committee in the United Kingdom provides Uniclass and Uniclass 2. And the “Catalogue des articles normalisés” was used in Switzerland even before computers were able to manage it.

Revit provides two built-in type parameters to manage such classification systems, the Assembly Code and the Assembly Description. These parameters allow us to link any Revit type to an existing classification system.


This classification system can be loaded in Revit through the Assembly Code interface.



Autodesk provides us with the Uniformat classification, through the UniformatClassifications.txt. This tab-separated values text file define the classification structure with four columns:

Classification Code - Description - Rank - Revit category Id
  • The Classification Code is the number associated with each item in a given classification. It is linked to the Assembly Code in Revit.
  • The Description is the text associated with each item of the classification. Once we add an Assembly Code to a Revit type, this description appears in the Assembly Desciption.
  • The Rank define the hierarchy of the item in the classification. This allows Revit to display any linked classification in a tree view.
  • Finally, the Revit category Id allows us to create a first mapping between classification items and Revit categories. This allow us to filter by Revit category while assigning Assembly Code.

To create such a mapping, we need the list of Revit categories. To extract this, I run a small routine to write every built-in Revit category to a .csv file. Along the way, I find some interesting properties of these categories. For example, the IsCuttable property list cuttable categories, something I was talking about in a previous post.

But most important here is an exhaustive list of all Revit categories, along with their Id, a prerequisite to create relations between Revit categories and classifications items.

These relations allows us to filter by category while assigning Assembly Codes.

You can find here the .csv file with all Revit categories, along with the code used to create it.

public void Categories()
	Document doc = this.ActiveUIDocument.Document;
	Categories categories = doc.Settings.Categories;
	List<string> categoriesList = new List<string>();
	foreach( Category c in categories )
		//Retrive sub categories
		foreach (Category subc in c.SubCategories) {
	string path = @"C:\categories.csv";

Grouping clash results

In any given building model, there is a number of issues to be addressed. A large part of these issues are what we call “hard clashes”, when a building component physically penetrate the space occupied by another building component. In these case, two or more building elements compete for the same volume.

Finding these clashes is now quite simple thanks to clash detection software that detect geometrical interferences between elements of a building model.

But after having a hard time finding these issues through coordination sections hand-drawn from plans, we now face the inverse problem and end up with too many clashes in our models. Running a simple clash detection can quickly yield thousands of clashes, making the entire process nearly useless.

Furthermore, a clash only represent a geometrical intersection between two elements, and is more a part of an issue than the issue itself. We have to group these clashes to be able to extract meaningful issues from the meaningless clashes.

Grouping these clashes is generally a manual task, and the user have to run through thousands of clashes to sort them in relevant groups.

While trying to automate this tedious task, I run across the examples provided as part of the Autodesk Navisworks Software Development Kit. These examples include a nice Clash Grouper plugin for Navisworks, enabling various method for grouping clash results.


As an example, I run a clash detection between the blue Selection A and the green Selection B, and get seven clashes, shown here as red dot:


With the Clash Grouper, I can group these clashes by grid intersection:


I can also group them by cluster analysis, where we search for the optimum grouping solution given the expected number of groups:


I also add my own method for grouping clash against a specific set. I use this to group all clash belonging to a single element in one of the two selection sets.


Here, I group by element from the Selection A (blue)


Here, I group by elements from the selection B (green)


If elements from one set are more relevant for the end user, the final clash report is clearer for this user when clashes are grouped against this set.

This plug-in enables a lot of possibilities for sorting clash detection results in a meaningful report, and will become a full-time member of my coordination toolbox.

To install this plug-in, you can copy-paste the ClashDetective.ADSK.dll file available here in a new ClashDetective.ADSK folder in C:\Program Files\Autodesk\Navisworks Manage 2016\Plugins. You can also see my edited version of the example code here.

Shared family

The Shared checkbox in the Revit family editor allows us to use nested families just like the root one.


Checking the Shared checkbox is only useful when this family is nested into another. When you load the root family into your project, Revit will also load the nested one. You will then be able to see it in the Project Browser and in schedules, and your shared family will behave just like any other families, except that it is nested into another.

This function is very useful to insert additional elements upon existing ones, according to specific rules.

As an example, I add a light switch to a door family. This light switch is wall-based, and will appear alongside of every doors in the project. As this light switch is a shared family, these instances appear on the electrical fixture schedule.


Furthermore, these nested families only appear in schedules if they are visible in the project. I use this property to select on which door I want a light switch. I add a Yes/No parameter on my family to control the visibly of the switch. Once hidden in the project, the switch doesn’t appear in the schedule either.


Using shared families is a very efficient way to insert elements in a model, and is a good starting point for rule-based modeling.

But once every light switch families have been inserted in the model through their host, we generally want to be able to adapt the position of some of these elements.

To do so, I wrote a few lines of code to create a copy of every nested light switch directly in the model. These new light switches are no longer nested, and can be easily modified to fit the local configuration. Furthermore, these elements are now electrical fixtures families, and can be added to an electrical circuit to perform load calculations.



public void ExtractNestedFamillies()
	UIDocument uidoc = this.ActiveUIDocument;
	Autodesk.Revit.DB.Document doc = uidoc.Document;
	//Select a family instance
	FamilyInstance fi = doc.GetElement(
			ObjectType.Element ).ElementId )
		as FamilyInstance;
	// Create a filter to retrive all instance of this family
	List<ElementFilter> filters = new List<ElementFilter>();
	foreach (ElementId symbolId in 
		filters.Add(new FamilyInstanceFilter(doc,symbolId));
	ElementFilter filter = new LogicalOrFilter(filters);

	// Apply the filter to the elements in the active document
	FilteredElementCollector collector = 
		new FilteredElementCollector(doc);
	ICollection<Element> familyInstances = 
	using (Transaction tx = new Transaction(doc)) {
		tx.Start("Extract Nested Familes");
		//Loop on all family instances in the project
		foreach (Element element in familyInstances) {
			FamilyInstance instance = element as FamilyInstance;
			ICollection<ElementId> subElementsIds = 
			//Loop on all nested family
			foreach (ElementId id in subElementsIds) {

				Element ee = doc.GetElement(id);
				FamilyInstance f = ee as FamilyInstance;
				//The fammily is face based
				if (f.HostFace != null)
					Element host = f.Host;
					Face face = host.GetGeometryObjectFromReference(
						f.HostFace) as Face;
					LocationPoint locPoint = f.Location as LocationPoint;
				//The fammily is host based
				else if (f.Host !=null)
					LocationPoint locPoint = f.Location as LocationPoint;
					Level level = doc.GetElement( f.LevelId) as Level;
					FamilyInstance fam = doc.Create.NewFamilyInstance(
					//Flip the family if necessary
					if (instance.CanFlipFacing)
						if (instance.FacingFlipped) {fam.flipFacing();}
					if (instance.CanFlipHand)
						if (instance.HandFlipped) {fam.flipHand();}
				//The family is point based
					LocationPoint locPoint = f.Location as LocationPoint;
					Level level = doc.GetElement( f.LevelId) as Level;



BCF Reader Update

This post is long overdue, but I finally take the time to update my BCF Reader.


First of all, I have tested it on a larger set of BCF files, and I hope these will make it more robust, especially if something is wrong within the BCF file. My experiences include files coming from Tekla BIMSight, Matteo Cominetti’s BCFier and Kubus BIM Collab.

I have to remove the support for Word 97-2003 Documents (*.doc), since the library I use does not support them. I will see how I can integrate them back in a future release.

Among the change, I add a small progress bar to allow you to pour yourself a coffee when dealing with huge quantities of notes.

I also add Status and Verbal Status to the report, just after the date. A more subtle change, the default path to save your report is now the same than the BCF file itself.

I improve the Readme file to include a small explanation on how to use the BCF Reader.

I spotted some problems with styles in the Word template. To be sure to have all of them available in the BCF Reader, you must write a few lines in your Word template, apply your styles to them, then delete them. This will ensure that you have created these styles in your Word template before using it.

Finally, I want to thank Julien Benoit and François Lahouste for their comments and their files.

As usual, you can download the BCF Reader here, and check the code here.