Rendering question

quote:

---

Do you make some kind of queue and render all at once?

---

Yep, the heart of our engine works in roughly that way.

The main reason is so that we can sort by rendering style to minimise hardware state changes (current texture(s), renderstates, shader handles etc).

Another thing it helps with is Z sorting when dealing with alpha - all alpha stuff which needs sorting (not all does) needs to be rendered after anything which writes to the Z buffer to work properly so we can trivially batch that too.

A downside is when you come to debug a problem, say the 23rd DrawPrimitive() call blows up, tracing back to which code passed wrong data to the higher level batching code can be a problem since the sorting means the rendered stuff is now in essentially a random order compared to the higher level game code. I''d advise augmenting your batching structures with some info to ease the tracing of bad data.

Our engine also allows a few advancements on top of the basic idea of batching, for example:

a) Display lists (OpenGL style) of draw calls with both inline vertex/index/matrix data as well as references to preloaded data.

b) All the draw calls from a particular frame can be cached to do things which take advantage of frame to frame coherence (e.g. "camera hasn''t moved so don''t clear").

c) Draw calls are added to a "view" - a view can be a viewport of a render target, a render target texture, a different monitor etc

["Draw calls" in our engine are higher level calls and command structures which specify rendering style, which matrices to use, which textures to use, which buffers to use, parameters for any shaders involved in achieving the "style" etc. A draw call only uses one style at a time so higher level model style (etc) grouping is the responsibility of higher level code]

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com