First, render opaque things, sorted near-to-far (sort by center of object dot camera forward vector).

Then, render transparent things, sorted far-to-near.

If your sky box is cheap, then render it first. If it's an expensive shader, render it between opaque and transparent, making sure that its Z is beyond all the opaque tings (typically using the viewport Z range).

Quote:Original post by BornToCode
What is the best sorting algo you think i should use. Quick sort or bubble. I once heard someone said that quick sort might be slower than bubble when sorting 3d objectst. I just want to know if i am right before i go and implement that.

I've used std::sort from the STL for alpha Z sorting in shipped Xbox & PC games. Its worst case complexity is O(N log(N)).

My advice is to try something like that first until Z sorting shows up on your profiling.

Some people use approximate bucket sorting methods where Z space is partitioned into a number of 'buckets'; the Z sort key value simply determines which bucket the object is in (e.g. if z>10 && z<20, insert_object_into(bucket[2])). Buckets are then rendered in order.

You can also probably optimise the sort based on knowledge of your scene - such as if the camera doesn't change too much from frame to frame, then the order of sorted elements won't change much either.

A far more important decision though is what Z value you use as the sort key - I'd go for the corner of the transformed bounding box that's nearest to the camera.

Quote:Also with that technique of rendering opaque objects from front to back, i can also use some sort of occludder on each object and see if they are occluding object behind them, that way i won't have to add those objects into the rendering list. But i was wondering how slow would that be, because for each object it would need to do n test

Occluder objects/planes are good and beneficial - as long as they're placed well in the scene. Anti-portals are probably the most common form, which are basically just the same as portals, except stuff inside the portal isn't visible and the stuff outside is visible (thus the 'anti' of the name).

You will have probably already transformed your object bounding boxes into camera space for the Z sort. Those transformed points can be re-used for your anti-portal test. Transform your occluders into camera space too, and the occlusion test becomes a 2D point in polygon test. You can approximate the (anti)portal further by taking the minimum 2D rectangle that fits inside it and using that as your occluder - the test per object then becomes "are any of these 8 2D points inside this 2D rectangle ?". That kind of test is usually much cheaper than the overhead of a draw call and associated set up work.

Quote:Original post by MrSparkle

Quote:Original post by hplus0603
First, render opaque things, sorted near-to-far (sort by center of object dot camera forward vector).

Why are you sorting by position DOT view direction?

It gives you the Z position projected onto the view vector. Consider the following (V is the view vector, C is the camera position, P1 and P2 are points to be Z sorted):

        V        ^        |        |        |               |              |       P1    |        P2   \    |       _/    \   |     _/     \  |   _/      \ | _/       \|/        C

If you take the distance from the camera, P2 is further away from P1 because its vector is longer, right?

Now think about what they look like when projected into 2D - they should be the same distance away from the camera.

The dot product onto the view vector gives you the proper projected distance (the distance between C and D below):

        V        ^        |        |        |               |              |       P1----D---------P2   \    |       _/    \   |     _/     \  |   _/      \ | _/       \|/        C

[edit]oops, mis-read the rest of your post Christian. The camera space Z would get you the same. I'll leave the above up so people know why the dot is used[/edit]