Updating Material with diferent textures, how many materials per object is bad

If i change the texture of a material (at runtime, change texture maps too, and offsets) it classify as a different material?
My question is, if a change the texture of the same material, color, offsets at runtime is that a new material or is the same material with a different texture/properties, if not what would it make it a new material?. (My idea is that the type of illumination used would change the material type, but I don’t know)

Also, is it bad for performance or some other reason to use several materials in 1 mesh, or when would it become bad let say 10, 5, 100?

Imagine you’re actually sitting down and physically painting ten toys on a workbench. Every time you need to switch colors of paint, you have to stop what you’re doing, and wash the brush you were using, and open the jar of the next paint, and then start settling in to paint whatever parts of the toys need the new color. If all ten toys need red and green and silver paint, you probably realize that it would save you time to paint all the red parts of all the toys first, then all the green parts, and then all the silver parts. It would be a lot slower painting one whole toy, and then painting the next toy, and so on, because switching paint colors is slower than switching toys.

When drawing a scene, GPUs like to continue doing exactly what they’re doing right now, for as long as possible. They hate having to switch what they’re doing, because that means it needs to throw out all the cached data it already has, and go grab a bunch of new stuff from memory. So an object which needs three materials is really three separate drawing tasks: the red parts, then the green parts, then the silver parts.

Unity automatically notices when more than one object is using the same material, and if it’s also in the same lighting conditions, it can organize its work into batches, just like the toy painting example. Batches are good. Individual special circumstances like unique materials take extra time.

If you modify an object’s material at runtime, and there’s more than one object using that material, it will clone the material so that your changes only affect the object you’re trying to change. The other objects keep using their old material, and the object you’re changing now has a unique duplicate on which to apply the changes. This takes a little time to perform this cloning operation, and it takes a little memory to hold the new material data. But once you do that cloning, this particular object does not have to clone it any more because it’s already a unique material for that object. The GPU does not know when this new cloned material is identical to other existing ones, so if you swapped red for silver, and then you swapped back again, it’s always and forever going to be a custom unique material that cannot be batched up with other materials.

All of that said, your game is your game, and sometimes you just need to accept the extra burden you’re putting on the GPU to get the look you want. Not everything can be organized into a nice neat assembly line of perfectly consistent tasks for the GPU to draw in perfectly optimized batches.

What you will need to do, and do regularly, is to measure your performance using the CPU and GPU profiling features in Unity. Learn what parts of your game are the worst-performing parts, and come up with ways to make them run more efficiently. If you’re trying to guess what’s slow or you’re trying to just improve parts of your code at random, then you’re wasting your time. Always focus on improving the worst parts that the profiler can show you with cold hard data. That’s called the “bottleneck” and it’s slowing everything down.

Thanks, that was a great analogy.