--------------------------------------------
Ok first of my observations is rather trival (a warm up?)
I’m used to 2 different naming styles:
- this_is_some_name
- thisIsSomeName / ThisIsSomeName
I prefer the second one, but I think I’ll have some problems getting used to this:
glTemplateAttrib<name type>_<value type>
I think I would prefer the ‘_’ character to be removed and to start from capital letter. We could probably even get away with not using capital letter in because it’s obvious that ‘ti’ means ‘template-integer’ and not ‘template index-NOTHING’, but in case there would be name conflict in future a capital letter is fine for me.
--------------------------------------------
Second thing that is on my mind is generalization.
We create a texture starting with:
glCreateTemplate(GL_IMAGE_OBJECT)
This defines what set of attributes this object template will have. Now imagine I want to do render to vertex buffer. Wouldn’t it be nice to have something like this:
glCreateTemplate(GL_IMAGE_OBJECT | GL_VERTEX_ARRAY_OBJECT)
Such object would have both attributes of a texture and a vertex array and could be used as both. It would be up to programmer to ensure that texels of texture overlap with vertices in vertex arrray (it could actually have a limitation to 4-components + power of two - others would generate an error upon creation of such combined object).
Of course there is a problem - it’s best to use interleaved arrays for vertex data. But as for non-interleaved arrays I think it could be possible to implement this on existing hardware.
For interleaved arrays it would require interleaved textures or multi-component textures (not possible to sample such texture, and when rendering to such texture it occpies few MRT’s) - that would require a great deal of flexibility from hardware so I don’t consider it very reasonable - for more complex cases geometry shaders or vertex texture fetch are the way to go.
Such object combination also allows to use glImageData2D on vertex array organized as grids, therefore allowing to pass let’s say heightmaps from CPU on the fly - especially usefull for etremely large terrain data streamed from system memory or HDD (only edges need to be updated when moving).
My point here is - textures / arrays / uniform sets (like the environment uniforms mentioned) - they’re all actually interpretations of some memory area on GPU - so should we allow to combine different interpretations (hehe, “render-to-uniform-array” ?).
I think that would require one more parameter to glTemplateAttrib:
glTemplateAttribt_o(template, GL_IMAGE_OBJECT, GL_FORMAT, _texture_format);
glTemplateAttribt_o(template, GL_VERTEX_ARRAY_OBJECT, GL_FORMAT, vertex_array_format);
Yes, I know it can be done with geometry shaders or even vertex shaders (VTF I mentioned before), but overlapping objects shouldn’t be very difficult to implement and will be easier to use than geometry shaders. It could also be faster because you don’t need additional shaders when rendering - there is only cost of updating.
Anyone out there thinks this makes sense or is it just me that should get some sleep?
Nah, I guess I’m a bit overworked lately, but I’ll post it anyway