I am making an attempt to implement a way for sorting my renderable objects earlier than drawing them into display. To take action, I’ve been tinkering with the concept of utilizing an 64 bit key to retailer the state of every rendering merchandise. Precisely as described right here: http://realtimecollisiondetection.web/weblog/?p=86
For example, for example I need to use a 16 bit sorting key to type per shader and mesh. Due to this fact, highest 8 bits will probably be to retailer the ShaderID and the final 8 for the MeshID.
I perceive the idea and the required bit operations used to mix ShaderID and MeshID into the 16 bits key. My most important situation is that I am not precisely certain which methodology to make use of for producing the 8 bits ID for every a part of the important thing (ShaderID and MeshID)
Looking the web and excited about it I’ve seen three attainable strategies, every with their professionals and cons:
Hashing Technique
Use a very good hashing algorithm and generate a hash worth for the Shader and one other for the Mesh (with a price distinctive per object so we do not use the identical worth to feed the hash). Then, use bit operators to transform the worth returned by the hash from 32bits (or no matter output the hash operate returns) into the required 8 bits and, lastly, mix them.
That is the strategy I’ve seen beneficial by most mavens and it appears good however, my most important situation is, that it would not appear to guard in opposition to collisions. So far as I see it, I may very well be unfortunate, compute the hash for my shader, flip it right into a 8 bit worth, and find yourself having the identical key as one other shader, as there are solely 256 attainable choices. Even when the hash is nice the difficulty may nonetheless occur even when I’ve nonetheless not run out of IDs.
Render Type ID Supervisor
As a substitute of utilizing a hashing algorithm. I may use a supervisor that retains an inventory of free IDs and returns a free one for every Shader or Mesh that requires one.
This offers nice management over every a part of the important thing. The generator offers keys that go from 0 – 255. Due to this fact I am certain there’ll by no means be any collisions and no two shaders will use the identical ID if they’re totally different. If I am ever out of IDs I can merely come out a message to inform efficiency may very well be degraded on account of unhealthy sorting and transfer on.
Predominant situation I see with this methodology is that it’s kind of reminiscence hungry. I must maintain totally different lists of free IDs for every a part of the important thing. In an actual instance I may have an inventory of two^16 integer for instance only for attainable texture mixtures. And there can be different lists for different components of the important thing.
Does anyone have any opinion on this matter? I’ve not been capable of finding any conclusive details about it.
Counter Technique
Merely use a counter that will increase by one for every sort of useful resource, so a counter for Shaders and one other for Meshes. Use the worth returned by the counter as ID for the useful resource.
This methodology appears incomplete as it would not take note of what occurs once I go above the variety of bits assigned for the useful resource. I may apply a modulo operator so as soon as I attain most worth supported by the render key, counter returns to the beginning, however this would not think about that I may find yourself reusing IDs which can be nonetheless getting used.
The benefit of this methodology is that it is easy and requires very low reminiscence.
Is there something I’m lacking? Do you guys use any of those methodology or one other one? I am a bit hesitant proper now.
Many thanks!
