Hi all,

I was still hoping to get a little help with the items mentioned in Post #16 and thought of another issue to think about.

When building render queues, 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.

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)? When the setup is like my existing implementation and everything's kind of homogeneous (everything's a model) it seems a little clearer, but what's the best way to be able to do this once the render system is taking over after a scene update for everything else (including models, but also extending into terrain and anything else)?

Thanks for your help.

Hi L. Spiro,

Thanks for the great reply. My issue was that I was thinking the RenderQueue was higher up in the hierarchy than it really needed to be. Moving it down to part of the graphics module makes the picture a lot clearer. And that's good to hear that going up to 128 bits for a key isn't uncommon - that seems to provide a lot more flexibility.

The only question I have left at this point is when it comes to shadow mapping. Basically, should models, terrain, etc., all know how to draw themselves to a shadow map, as well. That is, should these objects have both a renderStandard and renderShadowMap type of function that gets called at the appropriate time? The main reason this is an issue is that, while for most objects a simple transform vertex shader and no pixel shader works great, it obviously doesn't handle cases where features like alpha clip (needs a pixel shader), or tesselation (hull + domain shaders) are required.

I have a method of working around this in my current implementation, but it's kludgy and while I'm redesigning this part of my engine to be more flexible, I'd like to update as much as possible in one go. I think with that question answered, I'll be in good shape.

EDIT: Thought of another question that someone may be able to clear up. With the render queue items example explained thus far - how does the texture ID portion of it adapt to cases where an object uses more than one texture and/or a blend map? Should the render queue item just base its texture ID on the first one used, since that's the most common case, or should it somehow be able to store the IDs of all textures used?

Thanks for your help!

Thanks again, for the well thought-out response. I've already started building this out a little, and came to the same conclusion that you mentioned about texture IDs - if they're really varying after the first one (a very uncommon case), then it'll just have to be a sub-optimal draw.

Here's what I've come up with so far to describe RenderItems - items that act as the keys in the RenderQueue. I've gone with a 128-bit approach like you suggested, and while I currently have a lot of empty space, I think it's good to have that extra room to grow into as the engine matures.

/*
 * HIGHSET - Bits 128 to 65
 *
 * Bits [128 - 125] - 1111
 *   Pass type - Opaque, Transparent, Shadow (Other ?)
 *
 * if Opaque or Shadow
 *   Bits [124 - 109] - 1111 1111 1111 1111
 *     Shader technique ID
 *   Bits [108 - 93] - 1111 1111 1111 1111
 *     Texture ID
 *   Bits [92 - 87] - 1111 11
 *     Subset
 *   Bits [86 - 65] - unused
 *    
 * else if Transparent (these switch because transparency has to be sorted back to front)
 *   Bits [124 - 93] - 1111 1111 1111 1111 1111 1111 1111 1111
 *     Depth
 *   Bits [92 - 77] - 1111 1111 1111 1111
 *     Shader technique ID
 *   Bits [76 - 65] - unused
 *
 * LOWSET - Bits 64 - 1
 * 
 * if Opaque or Shadow
 *   Bits [64 - 33] - 1111 1111 1111 1111 1111 1111 1111 1111
 *     Depth
 *   Bits [32 - 1] - unused
 *
 * else if Transparent
 *   Bits [64 - 49] - 1111 1111 1111 1111
 *     Texture ID
 *   Bits [48 - 43] - 1111 11
 *     Subset
 *   Bits [42 - 1] - unused
 *
 */

        class RenderItem
	{
	public:
		uint64 highSet;
		uint64 lowSet;
	};

	inline bool operator<(const RenderItem& lhs, const RenderItem& rhs)
	{
		return lhs.highSet < rhs.highSet ? true : lhs.highSet > rhs.highSet ? false :
			// highSets are equal so compare low sets
			lhs.lowSet < rhs.lowSet ? true : false;
	}

	inline bool operator>(const RenderItem& lhs, const RenderItem& rhs)
	{
		return rhs < lhs;
	}

Is there anything you see that's definitely missing that should be there before going any further? One thing I know you've mentioned in a few posts is having a vertex buffer ID included. Currently my vertex buffer object is just a very thin wrapper around the underlying ID3D11Buffer object holding the actual data. It wouldn't be too much of a hassle to add an ID to each new buffer as they're created, though. Is this something that should definitely be added? Are there any other critiques, as well?

Thanks for all your help on this!

WFP

EDIT: Corrected the math around the bit layouts. More edits for formatting.

Just throwing in another idea that's a slight change on the render key approach that I'm trying recently:

In my hobby engine I maintain a list of sorted material instances - they're sorted by state, shader, texture and hashed constant data. They don't need much sorting after being loaded (changing material params or streaming in new materials requires another small re-sort). I sort these much like you would with a render key and maintain a list of indices into the material instances. Additionally, each material instance also knows its sorted index.

When I render, rather than trying to pack lots of info into the render key, I make use of the fact that the material instances are already sorted and simply use the material instance's sorted index + mesh data (vb/ib handles munged together) to then sort the data. I can also pack depth in at this stage since I don't need much space for material index (14 bits currently and that's overkill for my needs).