• Advertisement
Sign in to follow this  

Object/material/texture ids

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

I've just been through my engine changing my resource ids from a simple 1000+ incrementing id to an unsigned 64 bit integer using a hash made from the filename of the asset.

It has come about from the recent overhaul of my material system and material editor in my level designer. When I load a material, the ID of that material is created using the file name of the level designer version of the material (in-game I'll have a binary format including the saved 64bit ID). My meshes then each have a small lookup table which maps between the 64 bit material id to the DWORD attribute id so I can have the option to draw mesh subsets using multiple materials.

I was wondering if this sounds like a reasonable solution and how 32 bit systems handled their unique asset ids - hash codes/incrementing counters? I know they probably all did it differently, but was there/is there an industry-preferred method?

Share this post


Link to post
Share on other sites
Advertisement

For assets loaded from disk, I use a 32-bit hash of the filename as an ID, which is used to retrieve them from an asset cache instead of re-loading them.

I keep a debug-only file containing all names and hashes, to detect if there's a hash collision. If this ever happens, I'll either change the seed/salt used by the hash, or move up to 64bit hashes.

 

For runtime objects, I keep them inside pools (i.e. an array + freelist), and use the array index as an ID. To detect "dangling pointers" (where someone uses an ID after it's been free'd), you can associate a counter with each array slot which is incremented when that slot is released, and pack the counter into the high/unused bits of the ID field (often ID's only need to be <24 bits, which leaves space for this "ABA"/generation counter).

 

If that particular class of runtime objects needs to support contiguous access, then to allow compacting/defragmenting the array, I keep a second array of ID's to array indices, which allows the user to keep a static ID value, but the array index used by an object to change. This does add a double-indirection penalty though, so it's not the default option.

Share this post


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

  • Advertisement