I have a piece of code that activates the texture unit 0 but there is no code doing the texture binding (such as
glBindTextre(GL_TEXTURE_2D,texId)) following the glActiveTexture(GL_TEXTURE0). As a result, I am wondering if there is any way I can find what texture is being used at this point of time where i call glActiveTexture(GL_TEXTURE0).
It would be nice if i could find out the texture buffer object name/texture id variabe name instead of the GLuint number associated with the texture but I guess that’s asking for too much.
The project I am working on has textures bound at many places. So is it possible that you can do activate a texture unit and bind a texture and then just activate the texture unit later on (withoutrebinding the texture) and openGl would know that the texture you want is the one you bound a long time ago to the texture unit in question.
glGet-ing with GL_TEXTURE_BINDING_2D will only get the texture bound to GL_TEXTURE_2D. It won’t get a texture bound to, for example, GL_TEXTURE_CUBE_MAP; there’s a separate binding get for that (GL_TEXTURE_BINDING_CUBE_MAP). In order to know which texture you bound to which texture unit, you have to know it’s texture type.
The problem is that I have many types such as GL_TEXTURE_2D , GL_TEXTURE_3D bound to the same texture unit 0.
When I activate glActiveTexture(GL_TEXTURE0), how do I know which type is activates? If I had code such as glBindTexture(GL_TEXTURE_2D,texId)) following glActiveTexture(GL_TEXTURE0), then I would know which texture is being used.
The way things are in the project code …with only glActiveTexture(GL_TEXTURE0) , I don’t know which type or which texture.
All of them become active. Which one gets used depends on the sampler type in the shader. Or if you’re using the fixed-function pipeline, there’s a complex system of priorities for the different types that I don’t care to remember, since I stopped using fixed-function a decade ago.
If your driver supports the GL_KHR_debug extension, you can label GL objects with glObjectLabel (assuming you are using an extension retrieving library that is up to date, or you declare+retrieve the functions yourself). I think the intent of this extension is mostly to provide a common way for applications to mark objects for display in external debuggers rather than for internal application use though. For internal use you can use wrapper classes that contain the object id + name etc.