I have a small update... noticed that I had not defined the center point and radius for the objects in the scene, so it rendered them all(!), which was clumsy of me. After having added the needed data, it only drew as many objects as it should, though with slight anomalies.

Since I am using a CubeInFrustum function similar to that seen in some frustum tutorial, where you specify a cube (in thise case it is created from the center point of each object and goes the radius units in each direction) and compare it to the frustum, I wonder if someone else have gotten the same problems as I, mainly that some objects near the lower portion of the screen get clipped, while objects for off in the horizon still gets drawn. I am using a simulated isometric view, I look upon the world with a FOV of 90 degrees with an isometric concept in mind (I would not call it third person.. it's more like a bird's eye view of sorts). Could this be causing these problems?

Quote:Original post by blizzard999
But...if you are able to z sort polygons (for example with BSP) you cannot eliminate overdrawing!
In other words: you can say that a polygon is in front or behind another but you cannot say if it is visible so you must send it to the rendering pipeline (and you have no benefit).
Z sorting was good when computing z buffer was expensive...but today z test and texture mapping are 'free' (in terms of speed).

I never said anything about polygons, its all about objects.
Determin which objects are visable, do a rougth front-to-back sort on them and then draw a z-only pass (with or without ambient term).
The rough front to back order means you'll draw to a fragment the min number of times possible and can reject fragments that much faster (early z-rejection works much better under those conditions), hust throwing a poly soup at the gfx card wont help it at all.

So z-sorting IS good on a per-object level and while z-testing might be cheap texturing certainly isnt free, doubly so with shaders.

Look at it this way, if we didnt do a rought object sort and we had one object behind another but the one at the back was the first to be drawn then we'd do ALL the fragments for that object (on that pass) and then overwrite anywhere up to 100% of the fragments written for the closer object, which is a total waste of time.
If it had been sorted first then we'd draw the closer object and then only draw the fragments which are visable for the object behind it as the rest would get rejected by the z-buffer, saving a whole load of writes to the various buffers (z,color and any others active).

Made a simple distance calculation that works well. The frustum culling takes into account even the objects that are very far off in the distance, so I had to scrap that one. Well, anyways, thanks everyone :)