Texture buffers

OpenGL
1

Hi, I don’t know how much of this is usefull because of super_buffers, but I’ve been thinking about something to implement in my engine (a layer), that I guess it would be nice to see as an extension: texture_buffers

OK, since buffers and textures are all the same, I tought why to have buffers and textures? And not just textures? For example, a GL_RGBA8 would be a 32bit RGBA frame buffer… And a LUM8 or ALPHA8 could work as a stencil buffer and so on (more texture formats would have to be created)

Now, the thing is, imediatly after doing this:

glBindTBuffer(GL_COLOR, texID);

everything would be written to the texture (mip map level 0). If the texture was RGBA4 then it would be like drawing to a 16bit RGBA frame buffer. And if the texture was 1024x768, the viewport would also automaticly change to 1024x768.
After that command, everything would draw to that texture, without a depth/stencil buffer.
For that you would have to:

glBindTBuffer(GL_DEPTH, texID);
glBindTBuffer(GL_STENCIL, texID);

Of course, there would be some limitations because of viewport size and such… Another thing you could do is:

glBindTBuffer(GL_COLOR, texIDCubeFaceX);
glBindTBuffer(GL_DEPTH, texIDD);
glBindTBuffer(GL_STENCIL, texIDS);

//render stuff

glBindTBuffer(GL_COLOR, texIDCubeFaceY);

//render stuff

I assume that clearing (glClear, glClearDepth) would work on the textures…

For example, rendering to a mip map of a texture:

glBindTBufferMip(GL_COLOR, texIDCubeFaceY, 1);

Of course, most hardware would not support a stencil of LUM16 or whatever, but that could be like an extension string, letting us know of what combinations were possible…
I prefer this kind of API than the super_buffers… Of course the superbuffers is more powerfull, but a bit more “deselegant”…

2

It would be nice, but has some issues.

Originally posted by KRONOS:
OK, since buffers and textures are all the same, I tought why to have buffers and textures? And not just textures?

Because, in opposition to what you’ve written, textures and buffers are not really the same. Textures can be 1D, 2D, 3D or cube maps while buffers are always 2D.
As you mentioned, textures can also have mipmaps and buffers don’t.
Also, buffer size has no limitation like ‘power-of-two’.

And on top of that, you’re imitating just what über buffers are trying to achieve
With that said, if über buffers are going to do it, it surely means that in fact the aforementioned problems can be bypassed.

3

Yes, textures can be all of that, and the only ones that couldn’t be used are 1D. All others can be used. I gave examples of using cube maps, or mipmaps of textures…

And I used 1024x768 size textures, so already dependent on non_power_of_two extension.

I did say that the super buffers makes this look redundant. But looking at the specs of super_buffers, this kind of aproach looks a bit more “elegant”. At least that is what I think!

4

Originally posted by KRONOS:
But looking at the specs of super_buffers, this kind of aproach looks a bit more “elegant”. At least that is what I think!

Eh, sure. But looking at the first proposal of super buffers interface, everyone seemed to love it. Now that the interface has changed a bit, it looks like ugly (at least at first sight). Anyway, what’s important to note is that the spec is continuously changing, so we can expect it to be better until it the final spec is out. And by “better” I mean probably closer to what you’re proposing here