Painted Material Instance Parameter

[esatis]

Hi, 

Material instance parameters act very strange, they work as Material Type parameters. For example if you see image attached, I want to tag Painted Materials that each should have separate instance P_TENANT ID value, but it seems impossible. Seems like a bug. 

Any workarounds? 

[Basam.Yousif]

I'm not a fan of the PAINT tool. In fact, I teach people to not use it.

I recommend using parts instead. Here is a good tutorial: https://help.autodesk.com/view/RVT/2026/ENU/?guid=GUID-2B21C6A4-203C-4F85-B613-D2432AD95595

[RDAOU]

@esatis 

All what you need to do is add shared parameter to the Category Material. Then use a material Tag that uses a label with that SP (See GIF below

As for Parts ... they are not bad as a tool but can get messy and generate unnecessary work...Moreover, not everything is convertible to Parts. Hence, relying only on parts and/or not using Paint at all would practically get you to a dead end

[esatis]

Hi, yeah, we also tried that for a bit, but parts are not allowed in groups, and we use groups extensively. So that's a no-go.. 
Another downside is how Parts material area are calculated = volume / area. And of course Parts does not work for columns.

So for us, Paint with instance parameters would be best solution, but I guess it is not doable. And we just have to fall back to fake Paint finish walls.

[esatis]

Hi, 

that's what I did.

Now try to give same Material, painted in two places, different IDs, like I am trying. 

Even though you have created Material ID as Instance parameter (see image bellow) it acts as a Type parameter.

This functionality is needed to differentiate how much Paint area is needed for ''tenant 1'' and ''tenant 2''' etc.
For example, both sides of same wall are painted with same Material Red Paint, but they "belong" to different "tenants" -  ''tenant 1'' and ''tenant 2'''
That way I could get Paintarea schedule per Tenant.

[RDAOU]

---

@esatis wrote:

This functionality is needed to differentiate how much Paint area is needed for ''tenant 1'' and ''tenant 2''' etc.
For example, both sides of same wall are painted with same Material Red Paint, but they "belong" to different "tenants" -  ''tenant 1'' and ''tenant 2'''
That way I could get Paintarea schedule per Tenant.

---

Its the same "material" instance in the model (even when applied to 10 surfaces). You are trying to treat material similar to components when they are not.

What you need to do is identify the surfaces which are being painted per tenant/unit (example: instead of a Material ID add a Group ID to the walls being painted and instead of splitting faces split the components being painted. When the components being painted can be sorted by Group/Tenant, then so will the paint quantities be sorted as well

[esatis]

---

@RDAOU wrote:

Its the same "material" instance in the model (even when applied to 10 surfaces). You are trying to treat material similar to components when they are not.

---

I can't find any documentation on that. The way I see it: ''Material'' is the System Family, then I create these different Materials, which are Material Family Types. When I apply that Material Family Type "Red Paint" to surface, I create instance of that Type, as with any other Family Type.
That is why this feels like a bug.

But you are right, exploring elements with Snoop, I can see that all painted materials (with same type) have same ID, so it is applying same instance/type over and over again, which IMO is wrong. Just like with Walls, every Instance should have different ID.

---

@RDAOU wrote:

What you need to do is identify the surfaces which are being painted per tenant/unit (example: instead of a Material ID add a Group ID to the walls being painted and instead of splitting faces split the components being painted. When the components being painted can be sorted by Group/Tenant, then so will the paint quantities be sorted as well

---

This is what we are falling back to, just using Wall Type instances as Finishes.

[RDAOU]

@esatis  wrote:I can't find any documentation on that. The way I see it: ''Material'' is the System Family, then I create these different Materials, which are Material Family Types. When I apply that Material Family Type "Red Paint" to surface, I create instance of that Type, as with any other Family Type.

---

@esatis 

Well, one can always wish that materials were families.

Lets assume you’re theory or interpretation is correct. Where in the documentation you’ve read does it state that materials are families? And if they were families or objects, wouldn’t it be logical to edit them in the Family Editor rather than the Material Editor? Therefore, even if the documentation didn’t explicitly state that they are not families (which, in fact, it does), logic alone makes it clear that they are not.

For reference, you can check the Revit API documentation. Materials do not fall under the family category; they are handled as entirely separate elements within a different class hierarchy.

• Material: Autodesk.Revit.DB.Material
• Family: Autodesk.Revit.DB.Family

Good luck with your quest.

[esatis]

---

@RDAOU wrote:

@esatis  wrote:I can't find any documentation on that. The way I see it: ''Material'' is the System Family, then I create these different Materials, which are Material Family Types. When I apply that Material Family Type "Red Paint" to surface, I create instance of that Type, as with any other Family Type.

---

@esatis 

Well, one can always wish that materials were families.

Lets assume you’re theory or interpretation is correct. Where in the documentation you’ve read does it state that materials are families? And if they were families or objects, wouldn’t it be logical to edit them in the Family Editor rather than the Material Editor? Therefore, even if the documentation didn’t explicitly state that they are not families (which, in fact, it does), logic alone makes it clear that they are not.

For reference, you can check the Revit API documentation. Materials do not fall under the family category; they are handled as entirely separate elements within a different class hierarchy.

• Material: Autodesk.Revit.DB.Material
• Family: Autodesk.Revit.DB.Family

Good luck with your quest.

---

I am talking about System Families, like Walls.
System families (e.g., walls, floors, ducts)
Type: Autodesk.Revit.DB.WallType, FloorType, …
Instance: Autodesk.Revit.DB.Wall, Floor, …
Loadable (custom) families
Family “container”: Autodesk.Revit.DB.Family (one per .rfa)
Type: Autodesk.Revit.DB.FamilySymbol (a.k.a. “Type”)
Instance: Autodesk.Revit.DB.FamilyInstance
Materials
Autodesk.Revit.DB.Material is neither instance nor type—it’s just a definition that elements reference.

And every class above are subclasses of Autodesk.Revit.DB.Element

There is no documentation for Material that states either - is it a system family or not, that is just my interpretation of what seems logical to me.
So when I see instance Autodesk.Revit.DB.Wall I think that Autodesk.Revit.DB.Material should also be instance. It just seems that there is no Autodesk.Revit.DB.MaterialType

 Why is it not in Family Type Editor and not? Does not make any sense, but a lot of things does not make sense in Revit UI ¯\_(ツ)_/¯

Thanks for help and suggestions.

[RDAOU]

@esatis 

It feels like you are simply putting too much effort into make it sound right that Material are or should be either System Families or Families and I am not sure why. If you feel it is something which is so important and shouldn't be any other way, put it on the Ideas forum. 

The only thing I can suggest is to put more effort on refining your workflows rather than trying to bend the software to your will.