a lot of places I've been looking seem to recommend building out something of a descriptor key for each object - for example, a 64 bit unsigned integer where certain bits are reserved for shader id, texture id, pass type, depth, etc.
This usually comes from
this site, and while he has the right general idea, and while I have his invaluable book, with all due respect, he is not a graphics programmer.
In practice, you can almost never fit things into a single 64-bit integer, especially when you find 2 objects that have the same shader and vertex buffer and set of textures, etc. (which would make them a great candidate for instancing) but need to decide between them which to draw first, which of course always goes to depth (opaque objects should always be drawn front-to-back). A sort key cannot be fewer than 96 bits, practically speaking.
By now it should be obvious that if you are thinking, “How can I make this work?”, it isn’t because you aren’t getting something, it is because what they’ve described simply doesn’t suit what you need. It’s a fallacy to read a paper or a site and then get muddled in the details wondering why it won’t work for you. It won’t work for you because it wasn’t designed by you for you. If you need more bits, you need more bits. Just because he suggested it, 64 bits is not the standard, and if you need more then you need more. The idea, however, is still to reduce the bits you need to as few as possible. Don’t feel bad if you can’t get it down to 64. It has to be 96 anyway, and I myself always use 128 bits.
What should be responsible for filling this data out?
Should the model/terrain/water/whatever be able to fill this information out about themselves (and have to know what a RenderQueueKey is, or at least its format)?
Why not?
The graphics module doesn’t know what a model is etc. And a render-queue doesn’t need to care about those details either. It just needs to provide a structure and sort it.
If the model library, terrain library, etc. are all getting vertex buffers from the graphics library, there’s no reason they can’t also know the details they need to pass into a render-queue, also provided by the graphics library.
what's the best way to be able to do this once the render system is taking over after a scene
Trick question.
The graphics library is not providing any form of “render system”.
The scene manager orchestrates how objects are rendered. It relies on helpers such as render queues to determine the order in which to render, and each individual render is up to each individual object, so that terrain can do by itself vastly different operations from what standard models are doing.
L. Spiro