Immaterial?

Materials in Revit are a source of frustration, at least for me.

When it comes to documenting a project as it evolves from SD to subsequent, more detailed phases, Revit fails to provide a solid solution that acknowledges the need for continuity in documentation. Not that there are no ways around the issue, but we’re not after disconnected workarounds in the end. We want a solution that provides seamless integration between the 3D model and visualization aspects, and the documented information such as material schedules.

Let’s take rooms as the prime example. In itself, a room is not a physical object that exists on it’s own. You cannot buy a “room”: it is made up of walls, floors, finishes, ceilings, lights, electrical fixtures, casework, furniture…you get the point. Traditionally, we schedule room finishes in tabular format with a column for each element of interest. Now we can argue whether this is or is not the best way to show finishes, but guess what? We’re not going to change how the industry expects it just because Revit wants you to do it differently perhaps!

So how does one integrate the Materials in Revit with the documentation expectations? Over the years (and recently too) I have toyed around with several ideas but they all break somewhere:

• We can add a Material parameter to the room category. This gives us access to the actual Materials through a room object or a room schedule. Since a material parameter is a text entry pointing to a material name, it is easy to modify and doesn’t require you to take a trip to the Materials dialog if you know the material name.

• The first issue we encounter with the above is that we can only schedule the material name through the room schedule. We expect to see names such as “CPT” for carpet etc. in the room finish schedule. To work around this, we can name our materials in abbreviated form and also assign a common Material Class to easily filter these “Scheduled Finishes” from any other materials used for visualization. The advantage of using real materials is that if we decide to change the type mark or keynote, it will update anywhere that material is used/tagged in the project. This gets us closer to using Materials throughout the entire project lifecycle and not just for visualization.

Some comments about the above image: When are we going to see that darn Custom Parameters area be resizable instead of just tall enough for one parameter?? Also if you’re going to give us a Keywords parameter, let us schedule it! Otherwise what’s the point? Perfect use case: schedule filtering (ex: Keyword contains “Floor”). However for the time being, we have to add a custom project parameter assigned to Materials in order to do this (and scroll!).

• We need to schedule the materials used in the project together with relevant information, such as Manufacturer, Line, etc. However unless materials are used in a model element that is placed in the project, they won’t schedule. Sadly, rooms are not seen as a model element, so creating a Room Material Take-off schedule is out of the question (big bummer). In SD, I don’t care about the area or volume of material used (for documentation purposes, we hardly ever care except if we’re doing detailed cost analysis), but I care about the material description, the manufacturer, etc. I don’t want to schedule every single finish that exists in the Materials dialog, but only those called out in the Room Schedule. So having some sort of “Material Schedule for Rooms” is sorely lacking in Revit. If this were possible, one could schedule materials as they’re added to rooms.

During SD, we only have a limited amount of modeled information. Simply put, the need for “documentation continuity” mentioned earlier means that as the design is refined and the information granularity increases, it needs to find its place in the documentation infrastructure that already exists in the project. For example if all I know is that I’m using paint P1 on walls in Room A100, I need to show P1 as my wall finish in A100 in a room schedule and once that happens, the material schedule should automatically add material P1 to it with all the relevant info. about that material. As design progresses and we pick a real material, that information should be reflected in the material rendering appearance and parameters, resulting in richer, coordinated visualization and construction documentation.

How are firms doing this right now? Unless I’m missing something and there’s actually a way to achieve what I’m describing, we can safely say that firms are doing it the old way: just type it and coordinate manually. This is just not acceptable with all the BIMwashing and hype out there.

Currently, possible ugly workarounds include:

1. Making fake model families (ex: Generic Models) in some unused future phase and assign materials to them. This is synonymous with a physical “Material Sample Board” which is a standard thing in the industry. Now you create a material take-off schedule for the Generic Model category and go from there. However now we’re starting to have disconnected information: Just because a material schedules doesn’t mean it has been called out in a room schedule, and vice versa. Note that a similar technique is to use Design Options to segregate/hide these workaround elements in lieu of Phasing.
2. Typing it! Can’t get uglier than that. With this solution (sadly, the most common one), you manually type up & draft a finish schedule in a drafting view, which you then have to manually coordinate with materials used in modeling elements, room finish schedule dumb text parameters, tags, etc. This is as un-Revit-like as it gets!
3. Adding a zillion project parameters to the room category for each individual finish material application (floor, base, etc.) and then multiplying that by about 5 more (each one will need a unique description, manufacturer, etc.). Also with this you end up having to create separate schedules for each material application (Ex: walls) and…the actual Revit materials still have no connection to this information! This is the current solution we’re using in lieu of #2. It’s workable, but still not pretty. There are a lot of schedule gymnastics that need to happen to make it somewhat efficient.

Other shortfalls crop up while trying to make this work, such as the inability to have nested key schedules and the inability to use shared parameters in key schedules. But I’ll stop here today! Hopefully it is clear enough that we’ve exhausted a lot of avenues trying to get this to work and even though we build projects successfully, the software fails us from a BIM point of view. Despite these problems, we still love it and hope it gets better.

Immaterial?