I'm making a basic first person shooter, and am just starting to make a graphics manager after learning directX. I'd like to have some things clarified so I can design something decent: 1) My understanding is that z sorting my opaque objects (such as enemy characters) will allow me to take better advantage of the z buffer by not having to draw as many pixels. Is this true or is it that I'm simply supposed to not draw it to begin with if I determine something is completely obscured? 2) I'm thinking that to z sort, I'll keep a vector position for each object, and transform it with the world/view matrix to get the proper z component. This sounds rather expensive to me, so I'm wondering, is this correct/reasonable? A good link is appreciated if anyone has one. If anyone cares to make suggestions, my current plan is simply to sort by opaque/ transparent, then by effect file, then z sort the objects appropriately. Of course, this should put me on par with the Unreal 3 tech... or at least give me reasonable functionality to make a one man game. One or the other... ;-) [Edited by - Timptation on June 3, 2009 11:31:06 PM]

There is a small gain to be had when sorting solids from front to back. Imagine two objects, where object A is in front of object B, blocking half of it. Lets just say both objects take 10,000 pixels on screen.

If we render object B, then A, we'll render 10,000 pixels, then another 10,000 pixels, 5,000 of which overwrite the previous ones.

If we render object A, then B, we'll render 10,000 pixels, then only another 5,000 (as the Z buffer prevented us from shading the half obscured by object A).

If object B has a complex shader the time required to shade those 5,000 pixels can be significant. Now imagine a typical scene with lots of objects, often with several objects at the same screen point. A wall may be in front of a person, in front of a tree, in front of hill, in front of the skybox. The small savings on each object can add up.

The trick, is that switching shaders, textures, etc, all take time too. Perhaps you sort so that the order the shaders are rendered is based on which shaders have objects with the lowest Z values. How complex you want to get is ultimately up to you.

You both answered one of my questions and totally blew my mind with another optimization lol. That's very interesting. I don't think I'll be making anything complex enough to need to sort my shaders, but I'm wondering how I could find out which shaders are more expensive than others? I don't really know what profiling tools are available to the home programmer... or is that one of the functions of PIX (which i havent used much)?

Sorting by distance squared from the camera gives similar results to transforming them and sorting on z, and might be slightly quicker. You can also reduce the cost of comparisons by storing that distance value into the objects your sorting up front so you only need to do O(N) distance computations instead of O(N log N).

ATI have a GPU Shader Analyzer tool for estimating performance of shaders on a variety of cards. this is a similar tool for NVidia cards.

Quote:Original post by Adam_42
Sorting by distance squared from the camera gives similar results to transforming them and sorting on z, and might be slightly quicker.

That, and it is not even necessary to do a perfect sort at all. Run 1-3 iterations of bubble sort every frame (depending on how much CPU time you're willing to sacrifice).

While bubble sort has an abysmal performance characteristic to do a full sort, it is nice and easy to run one pass per frame, and this is entirely sufficient for the needed approximate sort. It won't give the perfect result during the first frame, but it will quickly converge over a few frames.
Other than most other algorithms, this gets the job done with a very low 100% predictable amount of calculations. There are no average and worst case considerations, the average case is the worst case (which is good).

I'm curious, why would we need distance squared? Squaring the distance on each wouldn't change their relative order right? Could we not simply use distance from camera?

Quote:Original post by Timptation
I'm curious, why would we need distance squared? Squaring the distance on each wouldn't change their relative order right? Could we not simply use distance from camera?

You save computing a square root this way. Eg:

float distanceSquared = *(x2 - x1)^2 + (y2 - y1)^2 + (z2 - z1)^2);
float distance = sqrt(distanceSquared);

Since as you correctly reasoned, the relative order is the same, there is no reason to waste computation time calculating that square root at all.