Is it bad practice to use many Material instances of Material Instances?

Development Rendering
1

So basically I’m considering branching of my Master Foliage Material (MM) into a Hierarchy of Material Instances (MI).

Currently I have MM_Foliage >MI_Grass_TypeX hierarchy for all my foliage, but I will have an absurd amount of foliage, and managing every Parameter for every single Object will become rather cumbersome.

So what I would like todo is to create several presets resulting in a Hierarchy like MM__Foliage>>MI_Grass>>MI_GrassWindLow>>MI_Grass_TypeX. I expect to have at least 1.000 different Foliage MI’s with millions of instances in the world.

Would there be any notable differences in runtime performance/memory usage compared to the MM>MI vs MM>MI>MI>MI workflow?

2

Using different Material Instances will create new DrawCalls when rendering.
Material Instances exist to reduce memory footprint, since Material Instances share the same shader code (except Instances with different static switches)

3

I’m aware of the basic principles of MI’s that you just explained. My question is purely related to the specific usecase I described above. Aka using many MI’s that only have 1 Parent Material vs using many MI’s that have a hierarchy of MI’s.

4

I’m not aware of any drawbacks of using child MIs for convenience purposes, but maybe others can elaborate if there are any.
personally for every complex material I always create a “MI parent” simply because if you ever have to go back and change a param value that propagates to all MI children, it’s easier to just change the value on the MI parent rather than re-compiling the material for a simple value change

5

I think there will be a big difference in runtime performance
Like @Raildex_ said it will create new DrawCall, so as per my i understanding moer DrawCalls more memory low performance
Cheers

6

I think what the OP means is wether to use MIs as a means to hierarchically manage the materials
think of it this way:

  • 10 foliage types that use 10 material instances that are all direct children of a master material
  • 10 foliage types that use 10 material instances that are children of children of the same master material

the amount of drawcalls will still be 10

7

Yes exactly, thank you.

8

I really don’t see why there would be any issue with using children of children of children etc. It all compiles to the same code since they all share the same master parent. Chosker is right, it should still be the same number of draw calls, no matter which way you do it.