Texture Arrays

So time to move further, I am planning to look into texture arrays and see if I can implement them by the end of this project( 4 weeks).

I have two questions:
Where the texture is bound to the geometry? “grep -R glBindTexture panda/src” returned only panda_glext.h.

How should texture arrays work?

Something like:

  1. A multi-textured model is loaded.
  2. Textures are stored in the Texture Array
  3. A vector of indices is returned to the user so that he can handles the textures directly ( I remember something about using a Texture Collection?).
  4. The model is drawn in one pass.

or I made it to simple?

Hold on, I misunderstood the request. I should implement texture arrays as another shader input only. Not the entire chain.

Look for GLP(BindTexture) in glGraphicsStateGuardian_src.cxx. (We use a macro to wrap most OpenGL calls, to allow explicit support for Mesa as a separate compilation.) Note, though, that this is just the OpenGL pathway; the DirectX GSG’s have their own, different mechanism.

I don’t think it makes sense to return a vector of indices to the user–texture indices are used only in OpenGL, not in DirectX; and it doesn’t make sense to expose this detail to the user. The user should deal only with Texture objects. (Unless you’re referring to indices into the texture array itself?)

I imagine the user would load a TextureCollection with the array of textures he intends to load, and set this on the ShaderAttrib. Then the GSG would convert this internally into an array of texture indices, which is delivered to the shader for processing.


I am referring to the fact that the user should know the position of the texture in the array if he want to access it in the shader. Makes no sense if the user itself load the textures, as the order could just be the same.

Then the GSG would convert this internally into an array of texture indices

I guess you mean doing something like this in glGraphicsStateGuardian::upload_texture_image(…) right?

 for(int i=0;i<n; i++){
    glTexSubImage3D( GL_TEXTURE_2D_ARRAY_EXT, 0, 0, 0, i, img[i].columns(),
        img[i].rows(), 1,GL_RGBA , GL_UNSIGNED_BYTE,load_image_data(img[i]));

Hum. I’ve just done some reading up on how texture arrays are actually implemented by the OpenGL and DirectX API’s. I had been fuzzy on the concept before, and I was thinking that an OpenGL texture array was just an array of existing and previously-loaded 2-d texture objects; I hadn’t realized a texture array is actually a unique copy of texture data, which all must have the same height and width, and which are uploaded to graphics memory using the existing glTexImage3d() call.

In that model, a texture array is very similar to a 3-d texture, whose layers can be individually addressed by the shader. Well, why don’t we follow a similar model, then?

We can just add TT_2d_texture_array to Texture::TextureType, and use the existing Texture interfaces to load these pages from disk or wherever. So there’s no need to use TextureCollection; the user creates a TextureArray by creating a single Texture object and filling it up with the desired contents. And this greatly simplifies the work needed by the GSG; it simply uploads the texture_array texture in a method very similar to the way it currently uploads a 3-d texture.


Hum, wait a minute, textures that are assigned as shader input are bound by the ShaderContext, not the GSG, right?

The binding of the texture is performed by glShaderContext::update_shader_texture_bindings(). But the loading of the texture data still funnels through glGraphicsStateGuardian::update_texture_image(), in both the shader and the FF cases.


I don’t have a big knowledge of how panda3D handles textures at the moment, but I was planning to follow the 3D-texture path. You guys, in an older post convinced me it was necessary to use a TextureCollection. I didn’t understand really well the reason at the moment, but I tend to trust more you than me… :slight_smile: