Jump to content
  • Advertisement
Sign in to follow this  
laeuchli

Texture GUID system

This topic is 4083 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

Dear All, I'm trying to design a texture management system. I like the handle method presented in Game Gems 1. However there is one change I'd like to make. Alot of the textures I'll be using will be ones without files names(portions of texture in a cache from a large database, and proc. textures). I'd like to be able to prevent the addition of duplicate textures. To do this I think I need a GUID for each texture, not based off the texture name. I've got a couple ideas of how to generate one(pick a couple of random spots on the texture, and use that to create a random number), or possibly use the texture size in conjuntion with that. Alternativly I could add every texel of the texture together, and get a seed from that(This seems slow). Does anyone have any opinions or experinces? Regards, Jesse

Share this post


Link to post
Share on other sites
Advertisement
The easiest approach would probably be to take the texture name and then append some extra information, such as a numbered suffix or pixel offset if it's a batched texture. This also makes debugging easier, since you can quickly see what texture is being used. Procedural textures can be named in code depending on their usage. For instance, give procedural textures a prefix of "Proc_" followed by a helpful name telling you what they're used for.

I can tell you from experience that it really pays off in the long run to have a simple system that's easy to debug :)

Share this post


Link to post
Share on other sites
Well I'll probably have something along those lines too, but what I'm really worried about it rejecting duplicate textures. Thus the need for GUID for each texture. Ideally I'd like two textures that are the same to end up with the same GUID regardless of filename or what not, so I dont have two of them running around.

Share this post


Link to post
Share on other sites
For disk bound textures, I compute a 128bit SHA hash over the entire texture data, and store it in the header. This is used to manage the texture database at runtime, and a simple reference counter is used to track (and avoid) duplicates. File size can also be used, but only if the texture are compressed (otherwise, the size will always be the same). It's not as good at avoiding collisions than a real hash, of course.

For procedural textures generated at load time, I simply use a counter.

Share this post


Link to post
Share on other sites
Thanks Yann, your replies are helpful as always. BTW are you still working on that 3D engine/Game you had screenies of a few years back? I remember it looked so far ahead of its time.

Share this post


Link to post
Share on other sites
One more quick question for Yann Did you use the MS crpyto kit for the hash, or did you just roll your own?
Regards,
Jesse

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!