occlusion culling

sup /prog/,

So I'm gonna make myself a isometric game that is built up with cubes so one of the important things to me is occlusion culling when there are a ton of cubes on that screen to be drawn. As of right now i'm making a quick java version for quick deploy and easy access with swing, etc.(Later it'll be ported to either C or C++).

As of right now i kinda have an idea of how i could attack this by rendering 2 frames. Here's how it would work:

1st Frame:
-Rendered from left -> right; front -> back
-As it's rendering it would check each cube based on it's hit box to see if it is covered or partially visible
-If partially visible(or completely) =>Draw cube; add to a Array containing all the cubes that will be drawn in the 2nd frame
-else => Discard that cube and move to the next one

2nd Frame:
Very easy render from right->left; back -> front with all of the cubes that will be visible in that frame.


In theory this method should work if implemented correctly, but my question to /g/ is does anyone know of a simpler more optimized way of doing occlusion culling(without using openGL or restricting myself to DirectX).

I'll ask the obvious question: how do you plan on determining which cubes are visible in your "first frame"? Regardless of the answer to that question, it's guaranteed that treating each cube individually will lead to a far slower solution than just drawing everything every frame.

VSD is one of the hardest problems in real time 3D rendering, and it's one of the main causes of shittily performing applications. Modern games (think Unreal Engine 3) use hierarchical delayed hardware occlusion queries. Going a bit back (Source engine, Unreal Engine 2) we have hybrid software methods including portals, occluders, and precomputed visibility (this last one in Quake derivatives including Source). Each method has a different set of trade-offs.

To answer your specific question, for a Minecraft clone, your best bet is probably to pack a bunch of cubes together (say, 10x10x10 units), frustum-cull these packs, then send each one as a batch in front-to-back order to the hardware. That's the best you can do if you expect landscapes where you can basically see everything from any given point. For closed spaces you might benefit from hardware occlusion queries, but this must be done very carefully as they have a significant cost. Here I'm assuming the world is dynamic enough that precomputing visibility is unfeasible.