you’ll see that he is sorting his batches according (among other things) material_id. To me material_id is synonymous with some tuple (shader program, textures, … other things …), but shader program and textures being the most important. Yet he does not mention textures or shader programs at all in the article. Are texture switches totally irrelevant when using shaders? I have read in these forums, that shader program switches are the most expensive of all GL state changes and that texture arrays solve many texture switching problems. Still, texture arrays have an id and it is probably not always the same for a given shader program.
Maybe some better article exists somwhere?
BTW: What is more expensive: a shader program switch or a shader pipeline switch?
Exactly, the program pipeline, have you played with it and did you do any benching?
As for the textures, a reader of the blog was wondering the same as me:
Another thing i was wondering; in most modern games you’d rarely see the same texture used twice, as about 90% of the rendered scene would be unique for materials (except maybe for the used shader). Would you then choose to only depth-sort and completely ignore materials if thats the case? In a typical scene i’ve seen theres barely any texture used twice, and if it is it’d be something used a lot, which would then be instanced anyway
But there was no answer to his question. I am basically wondering the same as he, does the material_id have to cover textures at all, or perhaps only the shader used.
It seems to me that the entire point of this system is to have the ability to quickly change things as you see fit. You pick a particular sorting algorithm (ie: number generator). Then you see how that benchmarks. Then you change it. And you see how it benchmarks. And you keep doing that until you find what works for your specific needs.
How much weight to give textures is one of those questions that is best answered by benchmarking for yourself. And this algorithm is designed to make testing and verifying as easy as possible. It may be that certain textures just won’t factor into it meaningfully. It may be that certain other textures do, particularly shared textures like shadow maps and the like.
I would first minimize program switches and then texture switches. To minimize texture switches you can use texture atlases and texture arrays. You can also assign some commonly used textures to fixed texture units, meaning you will hardly ever need to touch them. I only setup font texture unit once when I begin GUI rendering; other textures must use other units. I do same with shadow map when rendering main 3D scene.
I agree that only benching gives definitive results. However, whether to switch between program pipelines or shader programs seems a major decision to me that needs to be made before implementing the batching algorithm.