Jump to content
  • Advertisement
Sign in to follow this  
Ishraam

in a Material : TexturePtr or TextureID ?

This topic is 4435 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm concerned about a little design problem atm (C++). In my Material class, for a Texture inside it, should I store the TextureID (which can be used to access the TexturePtr through a ResourceManager::Find(...) method), or directly the TexturePtr? The 1st option is - slower (and having to Find the texture each time I want to work with it might be a perf-killer -- especially when using a std::map to store the pairs <resourceID, resourcePtr>) + but provides me a way to make sure the Texture is really available in memory (and if not I can re-upload it). The 2nd option is + the fastest, and the more straightforward - but won't there be problems like the one I described above ? (i.e. texture unavailable) Any feedback would be appreciated ! Thanks in advance ^_^

Share this post


Link to post
Share on other sites
Advertisement
Well, I've already pointed yout at my journal in another thread which addresses these issues somewhat.

Personally, I feel that storing smart pointers to the objects which manage the texture data is a better option.

Storage wise it costs a little more (4btyes for an int id vs sizeof(smartpointer to object), which is going to be 8bytes at least), runtime wise it will cost you less.

With an id system you have to go and find the texture resource you are intrested in, get back a pointer to the object and then act apon it.

With a shared pointer you can skip the (potentially) expensive first step of performing the search and as the pointer is shared you will always have the object to work with.

Share this post


Link to post
Share on other sites
Ok I hear you :).

I'm thinking the same way as of now; it somewhat seems kinda obvious.

Yet I'd like to know if someone already went the other way ?
Having feedback without the need to experience it myself would be great - especially since I don't plan to try it atm ;) .

Share this post


Link to post
Share on other sites
Quote:
Original post by Ishraam
...


Assuming you don't want to do stupid things, you'll never implement texture cache as a map, but rather as a vector. Thus Find is O(1).
During rendering, one don't want from a texture much - just some sort of operator != (), when sorting materials for example.
So, TextureID will do just fine.
Some sort of smart ptrs is generally not very advisable - passing them is more costly and can be easily used in a bad way.

Share this post


Link to post
Share on other sites
smart pointer == code coupling == bad

use ids and write functions that bind your textures on demand theres really not need to deligate pointers around.

Share this post


Link to post
Share on other sites
Don't forget there is some other interesting option, such as weak_ptr, providing you a way to nicely load/unload ressource. You could make a wrapper class around that, containing both a weak_ptr and the texture ID in case it's unloaded. If the class using a ressource with a shared_ptr release it, the object will be released as the texture manager only contains a wrapper class having a weak_ptr over this texture.

That way the texture class won't handle the caching/uncaching, only the wrapper class will do (it could be made abstract to implement static texture that never get uncached with shared_ptr instead of weak_ptr, procedural texture, etc...). I think all that caching/uncaching stuff shouldn't be in the Renderer part but in the Engine part, another layer of abstraction isn't bad...

Atm I do that in my engine, although I'm still thinking about other possibilities...

Hope it will help...

Share this post


Link to post
Share on other sites
Quote:
Original post by xen2
You could make a wrapper class around that, containing both a weak_ptr and the texture ID in case it's unloaded.

Isn't the TextureID + TextureCache->Find(TextureID) exactly a weak ptr..?
Or you mean weak_ptr just as faster access to texture data? I don't think you need such thing, inside the renderer.

Quote:
Original post by xen2
I think all that caching/uncaching stuff shouldn't be in the Renderer part but in the Engine part, another layer of abstraction isn't bad...


It is good to have a renderer, without even memory allocations inside. No smart pointers. TextureID is enough, imo.
Reference counting (if desired) can be made through texture cache, anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zemedelec
Quote:
Original post by xen2
You could make a wrapper class around that, containing both a weak_ptr and the texture ID in case it's unloaded.

Isn't the TextureID + TextureCache->Find(TextureID) exactly a weak ptr..?
Or you mean weak_ptr just as faster access to texture data? I don't think you need such thing, inside the renderer.


You're right, no need for ID any more as the wrapper class act for it, I'm sorry, just mixed things up, it was in my first version... ;~

I did it that way : First, note that Texture is an object in the Render library : no allocation stuff here (it's allocated in video memory on device->createTexture( size ) and deallocated on destruction).

Then on Engine side, a TextureSystem, having a vector of TextureHandle (the wrapper class). Then this wrapper class have a weak_ptr on Texture, and a ptr on a TextureSystem::Location abstract class which purpose is to load again texture if needed.

I though about getting back to ID as all the TextureHandle datas/functions could be moved again in TextureSystem, but my main concern is I didn't do the assumption there is one TextureSystem in the engine (with singleton) as it's often done (don't want to start the usual flamewar, but I think the user should have no restriction on making multiple TextureSystem). If I moved everything in TextureSystem, it would require a TextureID+TextureSystem* to reference a texture, so better have this TextureHandle class doing it.

Anyway I was thinking about it, I will change a bit the way it work, I'm not totally comfortable with the actual version.

[Edited by - xen2 on June 28, 2006 6:49:38 AM]

Share this post


Link to post
Share on other sites
Both options are fine, but I'm leaning towards the use of smart pointers myself. The whole idea of a texture cache is to be able to unload textures when they're not needed. If you use ids you will have to implement that yourself. By using smart pointers you don't have to worry about it.

Personally, I would use a TextureManager that holds a list of shared_ptr<Texture> and exposes a GetTexture(texture_filename) method. If the texture is already there, it just returns the smart pointer to it. If it's not, it loads it, adds it to the list and then returns the smart pointer. The renderable object is not necessary to request a texture ptr every time it is rendered, it could just require it upon construction and store it to a member variable.

Now, even if all the objects that use a texture are out of scope, there is still the list in the TextureManager that has a shared_ptr to it. From here on, it just depends on what you want to do: You could just keep the texture objects around in case any new objects in the future need them(faster loading-more memory hungry), or you can run a kind of garbage collector: If the refcount of a shared_ptr in the list is 1, you remove it from the list and the texture object is destroyed(slower loading-more memory efficient). It depends on the game and memory requirements really. If you are making an FPS with relatively small levels, the first option is fine. In the case of a huge MMORPG world, the second option would be the best solution.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!