Things are still progressing, I’ve added the GpuProgramUsage class to provide the link between Pass and it’s vertex and fragment programs; this also performs the cacheing of the program name and named parameters until such time as the program is loaded (important when you’re loading definitions from scripts and you don’t want to hog rendersystem resources until you absolutely need to).
I’m beginning to crystallise my thoughts on the impact of these changes on the rendering pipeline; at the moment a Renderable references a Material, and sorting is done on Material. With the advent of techniques and multiple passes, this will no longer be the case. Renderable will reference the Technique which it wishes to use this frame, and when added to the rendering queue, instead of one entry per Renderable there will be one entry per pass; the queue will do this automatically.
On the issue of sorting, I’ve been doing some thinking and I would like to make this a little more flexible than the simple Material sorting that goes on now. We’re going to be reordering each pass of a renderable now, not just the entire renderable. The bottom line is that we can reorder things however we like so long as:
- for non-transparent objects, the passes must be rendered in the order specified by the technique, although not necessarily immediately after one another
- transparent objects are rendered after solid objects, in depth order
Clearly we have little flexibility with transparent objects, so in this case the ordering will have to be strictly (depth, passindex). For non-transparent objects we have quite a lot of flexibility, so long as we ensure that passes for a given material are rendered in order. I plan to start with a fairly simple approach which is (passindex, textureunit0texture, textureunit1texture…). This guarantees that passes are rendered in order, whilst aiming for minimal texture changes. It also has the advantage of making sure we initialise the depth buffer using the first pass of every material for all objects before attempting higher level passes - for more complex fragment programs this can provide a significant speed boost if you use a simplistic pass as pass0 (maybe even with colour_write off so you truly are just filling the depth buffer) because the depth buffer will then eliminate more pixels immediately before they ever get to the fragment program.