[QUOTE=mhagain;1259365]One thing the atlas approach can’t do reasonably for you is mipmapping. At some stage you’re going to want to use mipmaps, and then you’ll definitely need to consider alternatives.
Sorting need not be overly difficult. The simplest approach is to use a qsort (or std::sort, or whatever your favourite sort API is) on an array of drawable objects. A second approach is to arrange your drawables as a set of linked lists starting from the texture that each uses.
One thing you’ll find is that using smaller textures is friendlier for your GPU’s caches too. If an extremely large texture needs to be swapped in, and objects drawn with effectively random access to that texture, it’s not going to be as fast as more coherent access to a smaller texture.[/QUOTE]
Hadn’t thought about mipmapping issues, that is a downside though. If I needed to scale the textures I just planned on doing it without any generated mipmaps.
I don’t think I can easily sort in my case here. I’m not depth testing so the order things are batched is the order they’re drawn to the screen, sorting would mess that all up. Using linked lists for drawables probably won’t be cache friendly at all. I could try it but I think I’d see a considerable performance hit.
[QUOTE=thokra;1259366]Why an array of atlases? You remove the benefical properties of an array of you fill it with atlases again. How many textures are you working with, does the amount surpass the amount of supported layers per array on the target hardware?
Ask it the other way round: what does a texture atlas offer you that a texture array doesn’t? Do you have many textures of significantly different dimensions, formats and so on that would lead to wasting a lot of memory or necessitate switching between an unreasonble amount of arrays?
BTW, if you really want the best bang for the buck, there’s also the so called sparse/bindless texture approach.
In general: for reducing overhead check out this most valuable presentation from GDC14.[/QUOTE]
I think a lot of the textures I’m using can be grouped into a small number of texture arrays but even though that’s true now it could change later on and I wanted to not have to worry about it.
I’ve read that presentation and watched the video on it, it all looks awesome. You’re the second person here, along with Dark Photon, to recommend using bindless textures so obviously I should be looking into it. I’m new to OpenGL and reading the docs; is this telling me bindless textures are only supported in OpenGL 4.0 and higher? If so, should I be concerned about the lack of support for OpenGL 4.0 in a lot of graphics cards? Or is that not as big of an issue as I think?