Adding Materials to objects - best practice?

[Simon_Weel]

We're struggling with Materials. I.e. how to apply them to objects. This can be done in a variety of ways, but which one is the 'best'?

At first, we thought Sub-categories where the way to go. Assign Family elements to a sub-category, and when loaded in the project, assign a Material to that sub-category. This COULD work, if only Revit provided a way to select a sub-category from a project into a family. It doesn't, so you either have to copy/paste between Family and project, or carefully type over the sub-categories name. But mistakes are made, ending up with a number of slightly different named sub-categories for the same thing. Another drawback: the Material doesn't show up in a regular schedule - only Material Takeoff schedules.

Now we're thinking about Shared Parameters for Materials. Instead of mapping a sub-category to a Family element, map it to a Shared Parameter. Then the Material can be scheduled AND modified from within a regular schedule.

For ease of use, those Shared Parameters should have a descriptive name. This means you need a parameter for just about every element type used in a building, resulting in an almost endless list...

That's not what I had in mind, so I wonder how YOU go about assigning materials in a project?

[Ilic.Andrej]

So many things on your mind 🙂

Well, this is how I would answer.

About scheduling:

The material take off is one thing while the category schedule is another. But lets assume that you wan't to schedule windows and show the material of the window frame. You can use any text parameter and it does not need to be a shared parameter. For example, you can use "type comments" etc... Lets look at another situation where you want to schedule faucets. But a faucet should be a part of the sink family. You simply make the faucet family shared and nest it to the sink family. Then, you can schedule sinks and faucets independently.

About materials:

When you load a family into the project, it loads the subcategories. So you should not be worried about that. The template file should have the families loaded already. So when making the template file, make sure you do everything correctly. But, you don't need to create any new subcategories for the families that are not a part of the template file. Regardless of the subcategories, every piece of geometry should have a material parameter assigned to it. The default material is "By Category" but the user can also assign the new material while not changing the material of the category or the subcategory.

About worrying that the user will mess up everything

He or she wont mess up anything because the template file will not be changed. Its important that you have someone who maintains a clean template. Be careful about the families which will be loaded into the template.

[L.Maas]

I do not think there is a best way. I think it depends on the workflow and requirements.

I have been working at different companies and the approaches were different.

At one  company we used the sub-categories method. We needed to be able to change the look and feel of the whole project often. By using sub-categories we could easily change the materials and have them applied to many different  families. In another company we used lots of different families. Each family has there own specific color(s). The colors were dependent on the model type (so more or less fixed). In this scenario all the materials were applied to the family. In case a family had different models within the same family we used a material parameter to be able to change materials between the types. As they used material takeoffs, a parmaeter for each material was not needed.

In short try to think how to work your project. This should help to determine which approach woudl work for you

[Ilic.Andrej]

---

@Simon_Weel wrote:

Now we're thinking about Shared Parameters for Materials. Instead of mapping a sub-category to a Family element, map it to a Shared Parameter. Then the Material can be scheduled AND modified from within a regular schedule. 

---

Now that I think of it, this may be very good idea. But I would create 3 or 4 shared parameters which have abstract names like:

Material A

Material B

Material C

Then you can use the shared parameter for any family, no matter if it is a window, door, furniture... The schedule headers can be renamed to match the description of the material. For example, you can use "Material A" to define the material of the frame and then rename the schedule header to "Frame Material".

To avoid mess, don't create 50 shared parameters. Use 3,4 or 5 shared parameters to control materials used in all loadable components.

[barthbradley]

---

@Simon_Weel wrote:

We're struggling with Materials. I.e. how to apply them to objects. This can be done in a variety of ways, but which one is the 'best'? ... so I wonder how YOU go about assigning materials in a project? 

---

K.I.S.S.-- Keep it as simple as possible, is my suggestion.  A material Type or Instance Parameter is as simple as she gets. Think you're struggling now? I can foresee major struggles associated with implementing, managing and maintaining multiple material Sub-Categories and multiple material Shared Parameters.  

Just saying...