Sign in to follow this  
_goat

Programming a texture

Recommended Posts

Basically, I'm writing an API-independant graphics engine. How do I write a texture class, to interface between whatever API (DX or OGL or what-have-you) and the user? I've looked, really looked, and there's not much on this topic out there.

Share this post


Link to post
Share on other sites
Base Texture -> (derived) OpenGLTexture
(derived) D3DTexture

then use a factory pattern to get the right one for your engine. In your base texture you want stuff like filename, if is selected by the API etc.

The derived versions have the actual API implementations for loading the texture to video memory, selecting with the API and such.

You might also want a special texture loading class. Instead of loading the texture into a sperate class each time you want to load it, it returns a referance to that textures class if it has already been loaded. This will help save on video memory and can also help to batch model drawing by texture. The beauty is that something like that would be API independant, so write it once and it will work with all your derived API texture versions.

Share this post


Link to post
Share on other sites
A couple months spent in the laboratory will save a couple hours in the library.

This is a case of needing to study the wheel and not reinvent it:

http://www.ogre3d.org/

just to name one of countless examples

Share this post


Link to post
Share on other sites
Regarding Ogre's texture management its not bad but I feel that particularly the base texture class tries to do too much - take for example the function to retrieve the depth - this is highly specific to 3d textures - so why is it not only available on 3D textures? For that matter why is there even an option to query the size of the texture at the generic level - all I have in my implementation is a function to bind the texture to a texture unit, which is implemented by the subclasses.

Currently my inheritance path then goes to API specific then texture type(1D, 2D, 3D, cubemap), but it is just as feasible to do it the other way around it all depends upon how I want to structure the code that actually uses the specific types.

So to give you an example of the flexibility I get to create a Shadow map texture - all I simply do is derive a new class from the RenderTexture2D class and implement the stuff that's specific to creating/binding a shadowmap - means I can almost directly copy and paste code straight from tutorials/documentation - easy!

Share this post


Link to post
Share on other sites
Quote:
Original post by jamessharpe
For that matter why is there even an option to query the size of the texture at the generic level


Isn't size common to all textures?

Share this post


Link to post
Share on other sites
whats the benefit of having API dependent texture classes? why not having a function in the Abstract Render API that will bind the texture and in that function the different API calls will go.

e.g. having this

class CTexture2D : public CTexture { ... };

// abstract render api class
class CRenderCore {

...
// bind the texture using API dependet calls
virtual void BindTexture( CTexture *texture ) = 0;
}

instead of this:

class CTexture2D : public CTexture {

virtual void BindTexture() = 0; // have API dependent calls here in the derived class

};

Share this post


Link to post
Share on other sites
Quote:
Original post by McZ
whats the benefit of having API dependent texture classes? why not having a function in the Abstract Render API that will bind the texture and in that function the different API calls will go.


That might work, but API-specific calls are also required when the textures are loaded, (glTexImage, gluBuild2DMipmaps, or DirectX equivalents)... I think that jamessharpe's suggestion sounds very flexible.

And I agree that the Ogre engine seems to overcomplicate certain things, like texturing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Aph3x
Quote:
Original post by jamessharpe
For that matter why is there even an option to query the size of the texture at the generic level


Isn't size common to all textures?


Yes but the number of dimensions isn't so a clean interface is difficult to provide.

Quote:

whats the benefit of having API dependent texture classes? why not having a function in the Abstract Render API that will bind the texture and in that function the different API calls will go.

e.g. having this

class CTexture2D : public CTexture { ... };

// abstract render api class
class CRenderCore {

...
// bind the texture using API dependet calls
virtual void BindTexture( CTexture *texture ) = 0;
}


By doing this you have to assume the method used to store a texture representation is the same for all API's which of course is not the case - DirectX uses COM objects and OpenGL uses GLuint's.

Share this post


Link to post
Share on other sites
well, then I might need to re-think my design a litle bit.

if I create a API dependent texture class like CglTexture2D would that one be derived directly from CTexture or should I still use the abstract CTexture2D class in between altough I can't really figure out why I would need that?

and then should I let the texture bind it-self?

e.g.
MyTexture->Bind();

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this