Hey I just want to confirm my understanding of texture performance -
The only constraints for number of textures are draw calls (which is really related to the number of materials).
For the quality of the texture, the only performance impact is the gpu upload upon initializing the material, which can be improved by using a supercompressed texture like .ktx or .basis. There is no runtime performance performance impact.
Taking these into account, I’m making an art gallery in threejs, and have come to the conclusion that the performance impacts of creating a material for every image vs. baking the images into one texture with blender are file size and initial material load, so no render performance impacts?
I’m trying to optimize as much as possible for mobile 
1 Like
no real render time performance impacts resulting from texture dimensions, no. if you write glsl shaders to handle most of your rendering you will find that you have a limited number of texture units per shader pass (16 i believe) and so combining textures for rendering ‘a page of thumbnails in a gallery’ might actually become a requirement. but, it’s more likely you have independent meshes/geometry for each item in your gallery (how most people would implement it.)
that said, gpu load time performance does not vary wildly depending on how you slice textures. 1 billion RGBA pixels over the bus is still 1 billion RGBA pixels no matter how it gets combined.
instead, i think you will find that other things are more effected by how images are sliced, for example; HTTP fetches incur network round-trip time for each fetch, and each fetch adds an envelope of, on average, 300-500 bytes, then there is the SSL stream allocation costs both at client and server, and suddenly “in aggregate” you incur size (network time) and compute (cpu time) costs on a per-image basis that wouldn’t exist if you combined everything into larger composite images. even if you overlap everything (scatter&gather algo) you still have those costs, and again “in aggregate” (multiple users) you eventually hit a capacity bottleneck that would be harder to hit if you had delivered composite images instead of single images.
personally i would test through both experiences, but i suspect combining textures is going to give a better end-result even if the GPU could care less.
That’s the main impact, but GPU compressed texures (ktx or basis) can also improve render time a bit in some cases. I’m not sure if that’s a noticeable effect in your situation.
Also note that mobile devices have low memory limits, and non-GPU compressed textures (like PNG or JPEG) must be uncompressed on the GPU. So a 4K PNG might be a very small file, but still consumes ~100 MB of GPU memory including mipmaps.
My suggestion would be to aim for <100 draw calls for the visible objects at any given time. If you think you can stay under that limit, then you probably don’t need to spend time merging textures.