Multiple Materials per Object- is it really "bad"?

Hi all, thanks in advance for your thoughts-

I'm working on some art assets that really work best with multiple materials, since they have multiple tiling textures on various parts (created via IDs and Multi-SubObject in Max).

I know I COULD bake out a single, simple, diffuse map- but this would lose all the nice up-close texture detail that tiling gives, and make things much more complex for me to edit.

I also hope to be able to edit these various materials via script mid-game, but that's another story.

Reading through the Unity docs, I saw that multiple maps per object is "bad for performance reasons". I would like to know, is this simply stating the obvious (more maps =, well, more maps), or is there something nasty that happens when doing this (ie, Unity just doesn't like it/deal with it well).

I would ASSUME that using 5 plain color maps + 2 256x256 maps would be actually better than a single 512x512 map even, or at least a 1024x1024. However, am I completley wrong? And would it be different if each of those materials were on a unique object (going back to the "it just causes issues when mult maps on one object" hypothesis").

Lastly, lets say I decide to keep these multiple materials per object- is there a way to control them individually? As in, I want to drag my own maps onto the object, and have it use those (since otherwise Unity keeps importing it's own...blarg).

Thanks!!!

 

The reason multiple materials is "bad" is that each material is a so-called drawcall. A drawcall involves things like loading a new shader, different textures, etc. This is normally an expensive operation (and unrelated to the amount of vertices involved).

That doesn't mean you shouldn't use multiple materials. It just means you might run in to trouble if you use multiple materials for every single object in your game. But even then there are methods to reduce drawcalls without sacrificing materials (look for "Mesh Combining" in the reference manual or on the forums).

 

Hi tomvds, thanks for the info-

to be more specific: i realize that, naturally, more materials = more work for the game. However, i'm wondering if all the materials being one ONE mesh is going to multiply the performance loss?

For example, which scene would perform better:

Scene A: One mesh, 6 materials on it. All materials are either flat colors or less than 256x256 texture, tiling.

Scene B: 6 meshes, all the same materials as above.

Scene C: 1 Mesh, one 2048x2048 map.

I'm certain other factors would normally come into play, but i'm most interested in knowing whether having all those materials on one mesh causes more performance loss than being on seperate meshes? Just making sure i'm not cutting my FPS in half due to some silly error

Thanks!

 

C would perform better. A and B are pretty much the same.

--Eric

 

If your using flat colour just make a colour chart and UV map so each mesh has its UV's on the correct colour. then all your objects only need 1 material.

 

This topic is something I've wondered about as well but I've put off until I am in an optimize phase. Thanks for the thread responses. When you say a color chart, do you mean just a texture with all the flat colors you're going to use and then do your unwraps in the proper section? If you use the same material for multiple meshes, is the way to save is to combine meshes? Right now I have a race car where the wheels, car body and driver are all different meshes. I could combine the driver and car ( he doesn't animate ).

 

thanks for all the replies, and glad to know maybe this will help at least one/two others out.

A few questions:

1)Tysoe- (slaps forehead) duh! I'll do this, definitely. Thanks!

2)Eric- That seems odd. A fairly gigantic 2048x2048 material would be BETTER than multiple flat color/small tiling materials? I suppose it only needs to be loaded/dealt with once, and I guess the situation could flipflop depending on the amount of memory available, to load up such a big'ol map. Then again, it is the only map in the entire level, so should be fine

Also, thanks for the B-A clear up. Good to know they play out the same.

3)Hyjinx- I would say you should keep your meshes separate, so you can animate them/edit later, easier. Then again, if you know for a fact you will never need them separate, I would def say to make them all one. My thoughts

Thanks again!

 

Texture size has little impact on speed; mipmaps ensure that few texels are actually computed on far away objects. Draw calls have a significantly higher effect on speed.

--Eric

 

@Eric, are you certain? C consumes more memory, but wouldn't that reduce the drawcalls to 1?

Cheers,

Galen

 

Yes, so it would perform better as I said.

--Eric

 

Ahh punctuation ... forgive me, I am apparently reaching the age where my eyesight isn't what it use to be

Cheers,

Galen

 

Well, it is just a few pixels after all; I edited it to make it more obvious.

--Eric

 

I went into my game and redid every mesh so that every mesh shared only 1 material in the entire scene. After I did that I got a performance boost.

But only when I optimized the shadows and lights did I see the huge performance boost I wanted.

Word to the wise, focus on lighting and shadows also along with draw calls and such.

 

A single pixel light can double or even tripple your draw call count if it's casting shadows. So you should keep lights to a bare minimum and try and use direct/parallel lights as much as possible since they are the cheapest.

 

I think a lot of this mesh/texture optimisation should be looked at in the context of your project and the target platform. Just like code optimisation, you could spend weeks reworking stuff for marginal increase with the project not moving forward. My horror project uses tons of materials/textures/lightmaps with hundreds of drawcalls but on my nvidia 8800GT i still get a framerate in the many hundreds.

iPhone dev is obviously different but I take each project individually when modelling and coding.

Regards,
Matt.

 

ufda, thanks for all the info

I was happily placing "force pixel lights" all over, when I noticed that the vertex lights looked terrible.

It's ironic, because I'm normally all about lightmapping- just this time the game would be best served with small unity lights

2 objects and 5 lights became 54 drawcalls, and another scene (these are all static-top-down scenes, only 1 object in the scene moves around) has 17 lights and 5 objects. yoiks, drawcalls must be ugly there...relative to what they should be, anyway.

I was using the dynamic Unity lighting because I hope to animate the lights in-game...maybe I will have to just bake it in (iPhone game). Will have to test and see. No shadows, at least.

 

oh, big question- say i lightmap all, is there a way to have the lights be vertex only, but ONLY affect specular, not actually light the object (dont' want them messing up my pretty pretty lightmaps )

 

this is very interesting and informative.

i am currently working on a project using only the material vertex colour and no texture and am wondering if this how this performs against using a texture.

it seems odd to think that using 6 flat material colours would be worse than using one large texture.

thanx

kieron

 

it depends on the hardware and shader ... depending on that it can perform better but if you get too many draw calls it will die totally

 

sorry i should clarify this is an iphone project. i am beggining to wonder if really the iphones hardware really locks you to a very narrow set of solutions.

thanx

 

gonzokawasaki - you're not really locked down to anything, stuff like optimising draw calls is just something to keep in mind. (so you don't make decisions early on that will bite you later, like building characters that each use 37 separate materials)

If your scene is modest enough it won't really matter how you construct it, but when you're trying to get performance out of your game or track down why it's grinding to a halt, these things are good to know.

 

Ok, sorry for the necro-thread-ing, but I'm looking for a bit more informations on this :
I'd like to tweak @yahodahan's example to make sure I'm going for the right solution :

What if, in Scene A & B, we are using the same Shader for all the meshes, but for Scene C, we use 6 different shaders? Is C still a better solution?

And, so that I would fully understand the answer, do Shaders have an impact on draw calls (or rather "batching", as it is the actual thing you want to reduce) or on the overall game performance? Thanks for your answers

EDIT : my bad, I was mislead into believing that I could have a single material with different shader while in reality, that would force me to create different materials...

 

It's not a problem to use many materials in your game. In fact, it's now recommended.

Draw calls are not a major performance issue anymore as long as they're not excessive, Unity also batches draw calls and you can set up your scene carefully to take advantage of this (for example all of those trees are batched) and having materials is better visually because it allows you to change the material properties on parts of the model like seen above.

I consider assets that have flat shading with a texture to be very low quality, because the texture then takes up a lot of memory and it's completely wasted. I would strongly recommend using separate materials to handle your mesh.

 

Not to necro a slightly old post, but someone mind explaining why this might be the case? AFAIK unity doesnt batch drawcalls unless sharing the same material.

In the case of flat shading (like in the image) it would seem pretty obvious to use either vertex colors or an atlas with small squares (color samples). Am I wrong?

Edit - I'm assuming he's referring to SRP batching in the LWRP. Would be interesting to know the performance difference between atlasing and just using multiple materials with the same shader.

 

For people who care, I did a small test on android/phone.

With a grid of houses, each house either using ... 1 material + 512 diffuse or 4 materials using a 256 diffuse each.

Difference was like night and day. Looking at the frame debug, the SRP batching seems to be working fine. Looking at the fps though, I'm getting around 14ish fps with the multi material setup versus around 50+ with a single. SRP is enabled in the SRP config. This is using raw models, no LODs.

With numbers like this, it almost seems as if SRP batching isn't working on mobile (or I'm doing it wrong).

Edit - BTW I'm using the "simple lit" shader for all the mats, which should support batching.

 

I apologize if it seems I'm spamming the thread, but this has quite large implications on my asset workflow.

So far I had been testing single meshes with either one or multiple materials (with or without LODs). What I didn't test was having a ton of single material meshes with different materials on each and to my surprise it made a big difference, to the point of looking similar to using the same material across all.

Inspired by this I tried splitting the mesh based on material use (still one fbx, just multiple meshes), but it didn't increase performance a lot.

So from what I can tell, it's ok to use different materials (don't need to atlas everything into one), however referencing multiple different materials on the same mesh should be avoided like the plague.

 

After a lot of testing, vertex colors are the best way to achieve this look with maximum speed efficiency! This allows the entire object to be batched as one piece.

 

When we are talking about batching, are we talking about toggling the "Enable GPU Instancing" option in the material? Because that can also significantly improve your performance for materials that you might see a lot from a single camera position (e.g. those trees and cars.)

If you want to know if your batching is actually 'working' (This one's for you Ng0ns) you can open the 'stats' bar in the game window and look at "Saved by batching". Check it the next time when you're not sure.

 

Batching refers to two processes: static and dynamic batching. GPU Instancing is related to batching in that it is a method of reducing draw calls, however it is more restricted and has higher performance gains. It works by storing the mesh on the GPU once and then drawing it repeatedly in just a few draw calls to fill out the scene. It's an extra feature that has to be added by the graphics programmer or you need to use a shader which supports it, such as the standard shader.

Static batching occurs when you mark your GameObject as "Static" in the Inspector. When you do, Unity builds it in to a large data structure with the rest of the static scene geometry to increase the render efficiency.

Dynamic batching occurs when multiple instances of the same mesh appear on screen, Unity will try to draw them all at once to save draw calls. To make this happen more often, make sure that the meshes are not mirrored and have uniform scale, and that they have the same material applied to them.

You only need to worry about batching if you have very dense scenes with a large number of meshes. In that case, reducing the number of meshes is a good start. You can also reduce the number of texture maps, as each extra texture on a material adds another draw call or three.

 

The main issue is that different materials break the batching. The new SRP pipeline should help against this as it allows batching of different materials using the same shader, but this unfortunately doesn't know for Android devices below Opengl version 3.1.

I'm unsure how people work around this, the difference is huge (was seeing a four fold performance difference just in my test scene using 4 materials). It would be a lot easier to use different materials rather than altasing into large sets (that doesn't tile easily), but performance would be abysmal on lower end devices.

 

My approach doesn't use textures so atlasses are not an issue. But you can do wonders with vertex colors!!!!

 

Damn. For the whole life I thought that A scenario will be way more preferable, compared to B in terms of performance. But I did a quick test and it seems that you're right. Thanks for the info. You've saved me a ton of work.