It will be good to have an extension that binds texture states to a name, similar to vertex array objects, but for texture states.
It would allow to bind min filter, mag filter, anisotropy level, etc. to a name for later usage
It will be good to have an extension that binds texture states to a name, similar to vertex array objects, but for texture states.
It would allow to bind min filter, mag filter, anisotropy level, etc. to a name for later usage
AdrianPi,
When you create a texture, you have an handle that is associed with it
=> you can easily make a tableau that make the association between this number and a string name and/or a more complex struct that save the states of this texture for example.
Because if you want to see a day a basic thing such as this to be integrated into the GL core, I think that you can wait a to long time ....for nothing ...
Personnaly, I have a day dream about an OpenGL 2.x that really use an object oriented scheme but that remain cross plateform independant ...
It's why, now in end 2009 and after lots of years, I see for to make my proper API that really use and propose a true Object Oriented scheme (but that use the "old good but really speed Opengl 1.x API" in his internal implementation, for compatibility and platerform independance of course)
Only because OpenGL 2.x is becoming all that you want but certainly not a cross plateform and independent API as before ...
@+
Yannoo
@+
Yannoo
By independent, I think about a lot of society that really work together on the same idea => make the better, simpler and stable Open Graphics Language that is possible.
@+
Yannoo
@+
Yannoo
For example, when an extension is proposed, that a software emulation is systematicaly provided with it for to to be allowed to name it glSomething(EXT or not) seem to me the minimum (for that this can easily to be added to the GL core if this is a good thing ...)
@+
Yannoo
@+
Yannoo
AdrianPi,
I give you two functions in one or two days : one for create/save the state on a texture with a name and another for to load/query the state of one texture by it's name.
@+
Yannoo
@+
Yannoo
Yann,
I just read all "4" of your contiguous replies, and I didn't understand a bit of what you're trying to say. Your meaning is getting lost in the language barrier. When you reply, please try to reply "once", and sum-up what your point is in a sentence or two.
You do know you can edit your replies for a while, right?
Yes, but I haven't always the possibility of make it
Now for example, I have only Reply, Quote; Quick Reply, Quick Note, Notify and Email Post ... but see nothing for to modify/compress my 4 replies to only one (you have perfectly reason, it's better to have only one response that a lot of responses where each does't say a lot of things).
(After the post, I have the Edit button, but not always. I have changed this post for add this parenthesis for example). (And sorry for my very bad english but I haven't found the equivalent thread but that speak in french ...)
What I have wanted to say is that we can effectively easily bind textures states by handles generated by glGenTextures ... but this method isn't the more logic/easy that we can think.
If we have the possibility to really name a texture with a real name such as "drapeau" or "ma texture a moi", this is very is more usable for all the world that a simpler number that systematicaly change in the next loading.
All people on this world have a name and a firstname and they aren't numbers.
If this work as this from a very very long time, it's certainly not for nothing ...
With textures handles that are really names, we can more easily share texture between independant OpenGL process and computers, exactely as we can easily share a file by his name on a network for example.
The other thing that I have say is that now for me OpenGL is really very very too slow to integrate something into the core. For me, this is only because two or three society make the war with the hardware before to begin to work about something that is generic and make in software, and so that can more easily to be implemented after in hardware by others OpenGL hardware competitors.
Direct3D make this really fast ... but this API is really a nightmare and no cross platform on the other side
What I want to find is the beautiful simplicity of OpenGL 1.x but with the latest and better technics for handle vertex arrays, multiples framebuffers and shaders.
And this is certainly not a lot of incompatibles versions of EXTs that can help OpenGL to have an unified API ...
PS : AdrianPi, I have make little functions that can handle texture states loading/saving by names (and not by number). If you have an email adress, send it to me for that i can transmit this to you
@+
Yannoo
@+
Yannoo
Yann, what you're saying is OFF TOPIC and you totally misunderstood Adrian's proposal.
(usually just hobbyist) OpenGL driver developer
When Adrian said "texture names", he was talking about the texture handles. That's just an alternate term for the same thing. He was not talking about using strings.If we have the possibility to really name a texture with a real name such as "drapeau" or "ma texture a moi", this is very is more usable for all the world that a simpler number that systematicaly change in the next loading.
That's also why the link I provided went to a thread where this had already been proposed. And, according to NVIDIA at least, it is being considered by the ARB for the next revision of the spec.
A bit more on-topic: exactly what state from the texture object should not be separated into a different object? I was thinking that the specific state on which mipmaps were active on a texture. Then again, it might be useful for ease of LOD-ing to have different state objects. However, it occurs to me that separating the mipmap state would only ever be important if you wanted different mipmap settings in different places within the same scene.
It just seems to me that the mipmap state is something that is intrinsic to the texture, like it's size and internal format.
Note that I'm not talking about the filtering modes. I mean the state that says which mipmap levels are active.
Posting Permissions
