I’m playing around with OpenGL 3.2, and it seems to me that binding textures really fragments what could otherwise be a pretty strait-forward batch drawing of primitives. IE: When drawing a bunch of 2d sprites, a vbo containing all of the data needed to draw them is trivial; however binding textures fragments the drawing calls.
The best I can think of is to sort by image and draw each range from the vbo, but if drawing order is important, and not related to texture… this may not help much at all.
It just seems to me that I should be able to pass an attribute to specify which texture to use… the texture is already in the gpu… so what’s the problem?
I could use texture arrays and all of my texture slots for a somewhat usable hack to get what I want, but it has it’s limits.
It seems nvidia’s bindless extension is meant for buffers only, not textures… unless I’m missing something. Now… there are texture buffers, which may? be able to be bindless. They come out as a 1d texel array with no filtering or anything, so not ideal either.
Does anyone know of something that would allow me to do this? Is there something I’m missing, or do I gotta just live with it?
The problems with texture-arrays are generally that they are limited to one xy size, and that z slices should be preallocated. The first is curable the way you mentioned, with conditional-branching: you could use 2-32 different sized texarrays, bound to different texunits. Or having each slice be an i.e 1024x1024 texture-atlas. (optionally do custom memory-management of spritesheets in those atlases)
The other way is to manage and blend texels manually, in a big preallocated buffer, but it’ll be slower. Or bindless buffers, which allow finer granularity and remove the need for defragmentation.
In the PS1 and PS2 days, devs had to manually arrange the scene’s textures and framebuffers in a single atlas ^^ .
IE: When drawing a bunch of 2d sprites, a vbo containing all of the data needed to draw them is trivial; however binding textures fragments the drawing calls.
How much image space could you possibly be taking up? Individual textures these days go up to 8192x8192. At 32bpp, that’s already 256MB of image data. And with texture arrays, you can basically have all of video memory as one texture.
Of course, it is up to you to segment the whole texture range into separate images. But that can be done easily enough with a few per-vertex attributes and varyings.