I was just wondering, how people implement their texture managers? For example at the moment my manager does this: * Reads a file with all the textures names, parameters, and paths. eg. TextureManager.init("worldOne.txt") * Binds a texture by name. eg. TextureManager.bind("rock"); * Unbinds texture by name. eg. TextureManager.unbind("wood"); * Binds all textures from the file read. eg. TextureManager.bindAll(); * UnBinds all textures. eg. TextureManager.unBindAll(); And in my texture manager I also have a struct which holds all the data. So, is this texture manager structure faulty, or correct? Is there a method missing which would be really helpfull? Any other idea how texture managers can be implemented? Thanks ^_^

To simplify, speedify:

Use a GetTextureFromName function to return the ID of a texture:
int GetTextureFromName ( String )

then have
BindTexture( ID )
UnBindTexture () //since you only bind one at the time (not multitexturing)
you should not need to specify witch texture to unbind...

a.

Here's what I would suggest to add :

- Multitexturing (GL_ARB_multitexture)
- compressed texture (ARB_texture_compression, GL_EXT_texture_compression_s3tc)
- Mipmapping (GL_SGIS_generate_mipmap)
- Support DDS file format ? (http://users.pandora.be/tfautre/softdev/ddsload/)
- Create texture from memory
- Texture as render target
- Save a texture as a file (ie : screenshot)
- Support non power of two texture size
- ....

Good luck :)

heres what i have (bit messy), these are all managed by a texture manager, handy function is to unbind all textures and recreate them if u change the windows context eg from a window resize

struct Texture
{
Texture() { textureID=-1; pixels=NULL; texture_came_from_file=false; is_a_compressed_texture=false; generate_mipmaps=false; pixels_have_mipmap_data=false; strcpy( texture_name, "bollux" ); keep_pixels=false; texture_border=0; }
~Texture() { if ( pixels ) { delete []pixels; pixels=NULL; } }

GLuint textureID;
char texture_name[ MAX_FILENAME_LENGTH ];
GLubyte *pixels;

bool texture_came_from_file; // some are constructed from data in the program eg shadowmaps, usually though theyre loaded from the HD
int texture_target; // GL_TEXTURE_1D GL_TEXTURE_2D GL_TEXTURE_3D GL_TEXTURE_CUBE_MAP
int texture_width;
int texture_height;
int texture_depth;
int texture_bd;
int texture_border; // normally 0 but some tiled textures will have borders of 1
int internal_format, base_format;
int base_memory, totalmemory; //totalmemory is the memory+mipmap memory
int num_mipmap_levels;
bool generate_mipmaps, pixels_have_mipmap_data;
GLint min_filter, mag_filter, wrap_method;
int priority, residency;
int texture_size;
bool is_a_compressed_texture;
bool keep_pixels; // tells us wether to delete the pixels when we've created the texture or not, eg sometimes u want them sticking around eg when u update a texture

bool loadJPG ( const char *filename );
bool loadDDS ( const char *filename );
bool loadTGA ( const char *filename );
bool loadImage ( const char *filename );

bool saveTGA ( const char *filename );
bool saveImage ( const char *filename );

bool create_opengl_texture1D ( void );
bool create_opengl_texture2D ( void );
bool create_opengl_texture3D ( void );
bool create_opengl_texture_cubemap ( void );
bool convert_pixels_to_a_normalmap ( const float heightscale );
void update_GL_textures_info ( void );
void workout_image_size ( void );
void workout_internal_and_base_formats ( int IF );

void flip_Texture ( void ); // with some textures the origin is at 0,0 with others its at 0,1

void update_all_textures2D_pixels ( void ); // calls texsubimage to upload new image data into a texture

void log_texture_info ( GLtexture &gltex, const int spot );
void update_GL_textures_info ( GLtexture &gltex );
};

mine can load a texture by name, uid (an integer it is assigned in my "texture list" data file), or opengl textureID, and each time it returns a pointer to a struct that holds the opengl texture id (this struct is stored internally to the texture manager) and some other stuff.

this way, when something needs that texture it can ask for it, and after that it has access to the texture id it needs. plus, if i lose the context (i.e. an alt-tab or resolution change or whatever) the texture manager can automatically re-load the textures currently in use, update the structs, and everyone still has their (new updated) texture id already.

still working out some bugs of course, lol...

Thanks guys, this ideas are going to leave me programming for a couple of days. :) Yay.

More suggestions or different structure examples are always welcome. Please keep posting. Thanks.

I'm interested in the way one can handle the multitexturing way with texture manager. Anyone an idea ?

I see a few people here have LoadJPG, LoadTGA etc in the texture manager. My system is a bit different (only recently changed it).

I have a general resource manager. This resource manager is the only one who interacts with the filesystem (it reads an entire file into a buffer). This buffer is passed into functions (that can be registered with the resource manager dynamically). The functions are LoadJPG, LoadTGA, etc. These routines return a CTextureData struct. This contains the actual texture data, but this is still unusable. The struct is passed into a CreateTexture function. This can be API dependent. It creates a CTextureObject class which holds all info needed to use a texture with the chosen API. Users only interact with CTextureObjects.

For multitexturing, I plan on having static id's for each texture unit. Textures can be bound with:

void CTextureObject::Bind( unsigned int textureUnit = 0 ) { ... }

If you don't want to use multitexturing, you can just call Bind(), and if you do use it you can easily bind it to a specific texture unit.

Quote:I have a general resource manager. This resource manager is the only one who interacts with the filesystem (it reads an entire file into a buffer). This buffer is passed into functions (that can be registered with the resource manager dynamically). The functions are LoadJPG, LoadTGA, etc. These routines return a CTextureData struct. This contains the actual texture data, but this is still unusable. The struct is passed into a CreateTexture function. This can be API dependent. It creates a CTextureObject class which holds all info needed to use a texture with the chosen API. Users only interact with CTextureObjects.

similar to what i do, i call loadimage() and then the appripriate loader is called to load the texture data, once u have this data u create the texture

also multitexture is in no way linked to a texture manager, so it shouldnt be mentioned in the structure, it belongs as part of the renderer structure