A while ago, I asked a question about how to properly organize your render loop (http://www.gamedev.net/topic/659636-good-render-loop-organization-resources).

Haegarr gave me some good advice about doing visibility culling and about putting specific render jobs for (among others) opaque and non-opaque objects in separate render lists.

In those rare moments that I do find time to work on my own projects, I have already implemented a basic octree implementation for visibility culling, but I am now faced with the problem of sorting my render lists.

As I understand, one would want to sort an opaque object render list from front to back, in order to trigger early z rejection, but I was wondering how you could combine this front-to-back sorting with sorting objects to minimize resource switching.

Correct me if I'm wrong, but either you sort objects by their distance to the camera, or you do it by some other criteria, but you can't do both right?

First of all, the most important thing is to sort non-opaque (translucent) objects back-to-front, otherwise they'll (probably) be rendered incorrectly.

For opaque objects you'll have to find the best option for you specific project.

Option 1: Sort by depth front-to-back;

Option 2: Sort by "material"

Option 3: a mix of (1) and (2) - put "material id" in the higher bits and depth in the lower bits, this way you minimize resource switches and still benefit from occlusion tests (early z) in objects using the same resources.

Option 4: a mix of (1) and (2) - do a rough sort by depth (basically you round down the distances) and then sort each bucket by material (not really two separate sorts, just put the depth in higher bits).

More info at: http://aras-p.info/blog/2014/01/16/rough-sorting-by-depth/

Example:

Object A (distance 12)

Object B (distance 25)

Object C (distance 17)

If you round down the distances and sort by depth:

Object A (distance 10)

Object C (distance 10)

Object B (distance 20)

You can also sort A and C by material, and they're drawn before B

Depending on your project this might be an improvement (maybe you have many objects using the same resources close to each other), but you have to profile different methods to find what works best for you.

Ok, sounds like a good way of doing it. Basically it boils down to roughly weighting your different sorting criteria by what would give you the best performance boost?