@inteja I have not done any hard profiling about one material with a larger texture set - I normally limit myself to 2K as the largest possible texture size - and several materials. I think you could possibly get some trends with this, but there are a lot of variables that will have an impact and could possibly be tuned to find a middle ground between one and many materials.
One of the simplest is that more materials will mean more meshes to apply those materials to. So you are going to incur further draw calls from additional meshes when splitting materials. However, you could combine several materials (in your example, maybe a few cushions and legs in one material and the rug and sofa structure in another) into non-tiling atlases to maximize UV space. You can then use smaller texture sizes with the same texel density as all UV islands in one large texture and not lose any fidelity. This could get around any browser limitations that @labris mentioned, while still maintaining fewer materials and meshes resulting in fewer draw calls.
However, you could go about it another way. Really, the only texture that needs an atlas unwrap is the AO map. The rest could be a combination of tiling textures that are much smaller. A 128 x 128 texture of the sofa material could be more than enough if the texture tiles enough times on the model. In this way, you could use several UV sets to unwrap your model depending on the texture you will pass to it. This means you can have one larger texture, and many smaller textures based on UV set. In this This would also be a reduction in overall file size for download while maintaining fewer draw calls.
You could also go with a single node material and many smaller texture sets that wire into one material and break based on any number of methods (UV set, UV position, Vertex Color, etc). I have an example of this type of approach using UV position to break between texture sets that passes three different PBR sets of textures (two with emissive maps) each to a section of the single mesh in the scene.
You may find, however, that this method is slower based on fetching each pixel from the shader three times before selecting which one to return based on your scene or the size of your textures and it may be faster to split the meshes and materials.
I don’t think there is a set right answer here because there are a lot of moving parts. In some instances, using one material and mesh may be the best because you have a lot of meshes to load and manipulate in your complex scene. In other cases, you may be loading a single glTF and so having multiple meshes and materials isn’t that big of a hit to your performance.
@carolhmj is working on the final implementation of the performance profiler that @SahilTara built for his summer internship, so you will be able to use that to do some testing in the near future. In the meantime, I hope this helped frame your thinking about the issue. Feel free to bounce back more questions as you think through the problem.
