Absolutely not. The render-queue is nothing but a very small set of integers (or a single 64-bit integer if possible) which contains data needed for sorting. That means a shader ID, texture ID, any small ID numbers that you want to include for sorting, and the fractional bits of a normalized (0-1) float for depth.Should the renderQueue be aware of updating/creating resources (loading vertices in a VertexBuffer?).
Sorry for hijacking this, but I have a question related to this. First, in my Engine, which uses a similar design to imoogiBGs DrawCall-Structure, my rendering-queue is a std::vector which holds the pushed DrawCalls of the current frame. These then have their Sorting-Key stored inside them and implement the <-operator.
Now, I thought about maybe putting the key and a pointer to the structure it represents into a pair to use this for sorting for better cache locality. I guess since you explicitly say it should only store the keys as integer and nothing else, one should go with two lists for each queue where one contains the states and one the keys? After doing sort which gives doesn't move the data, but rather generates a set of new indices for the values you could use that on the list of DrawCalls?
Then, secondly: I have read a lot about the stateless approach and everywhere only saw people talking about storing the id-values of the shaders, buffers or textures. That makes sense for OpenGL, but how would I access the objects for something like D3D? As said, my current structure for D3D11 stores the pointers to the different ID3D11*-Objects a drawcall needs. Of course I could put everything in a hashmap, but I don't see why I should do that when I could store the pointers by having a class that understands the current API and pulls the data out of my generic buffer and shader structures.
Thanks in advance!