Sign in to follow this  

What culling method would be best for cube land?

Recommended Posts

MarlboroKing    252
Cube land.. Lol. I'm 'immitating' Minecraft, like everybody else. I'm debating against the two: Occlusion Culling & Ray Casting.

At the moment, I'm using this as a helper (and some code too...!):

I tried using the LPDIRECT3DQUERY9 interface for occlusion culling but my scene rendered extremely slowly (screw up on my part...?). I usually got 15 FPS for drawing 6963 cubes and the 12 faces it has. I read that an Octree would be a good choice to help determine what the 'neighbors' are of a certain cube, but at the same time, I don't think an Octree would be good for a game that already splits its world? Or is this question/statement just complete jibberish.?

Occlusion Culling (or just this method I used? not sure lol) seems to be aimed for more pixel-perfect culling, which I believe would NOT be necessary for a game such as this. Ray Casting, I haven't looked too much into so I can't really output an opinion and/or a stupid opinion about it.

I'm basically running back and forth between the two (Well, three: Occ-culling, Ray Casting & implementing an Octree) from various websites where others are discussing -semi- the same thing and reading mixed (biased?) opinions about it all.

Share this post

Link to post
Share on other sites
Kaptein    2224
i'm doing occlusion culling.. everything is ultra-optimized and profiled to death

150,994,944 blocks gives around 1000 +/- objects to draw with the best balanced approach
when the camera is changed, i have to run a boulder-worth of efficient culling (including major-direction, which very few people even have heard of)
the average fps when moving in a world thats more or less (i'd say) decently full of blocks is 30... yes, 30 fps
note that when moving, the camera is updated intermittently, and so the fps is alot lower than when stationary

i should probably mention that my shaders are very heavy, so that will definitely affects things, BUT i am cpu-bound!

verdict: don't use occlusion culling and raw power, it doesn't work if you have any ambition at all :/
it works like a charm for 67,108,864 blocks though
but, this approach is very very CPU heavy! it doesn't scale at all!!

edit: to answer your questions
1. octtree is good for you, since you don't know about it (assumption!)
learn to use it, then when you are confident, write your own super-fast version and profile it to death.. unless you go straight for raytrace

this kind of project is really really hard to pull off.. i have coded for many years already, but this project is killing me =)
i feel like a beginner again :)

2. there won't be much beginner stuff you can learn from to make this project happen
in my case i just started coding, and did reiterations on everything again and again until i knew better... its the wrong approach definitely!
but, i don't want to deter you from working on your project - so my advice is try to find a good existing voxel library
and anything that has to do with raycasting is your best friend :)
the whole point of trees and raycasting is to work with lots of data and do VERY few iterations on it!

iterations are the main thing that will hold you back, just like it does me, so keep all the numbers visible at all times so you have an idea on where you stand
any number that is > 1000 = failure! nothing should run more than 1k times!
in my case, i had to do quite abit of processing on the blocks, such as counting lowest and highest point, sorting the blocks into different types
and eventually assembling the block meshes into bigger "columns", because it's much harder to be gpu bound :)

if you have any specific questions you can just ask me Edited by Kaptein

Share this post

Link to post
Share on other sites
larspensjo    1561
The way I do it:[list=1]
[*]Group blocks into chunks.
[*]Pre-compute list of visible surfaces for every chunk. That is, faces from blocks that are adjacent to "air" or whatever.
[*]Cull chunks that are outside of the view frustum.
[*]Sort the chunks in order from near to far.
[*]Define bounding box for each chunk.
[*]Use queries for N chunks, repeatedly, and then draw those that were visible. N has to be "big enough" to make sure the query is finished. This is tricky, as it may work perfectly on a test setup, but may induce stalling in other combinations of HW.
The idea of testing the query in next frame, as explained in the link, is tricky. If you turn quickly, some objects can lag behind, creating temporal artifacts. This can be solved by simply setting the default to draw all cubes, and cull them the next frame again. But then you may get intermittent lag when turning

The way to use early Z is also tricky. It won't work when turning, for example.

I think this is the challenge of voxel based games. To get an efficient drawing, while still using blocks that are small enough.

[quote name='Kaptein' timestamp='1348213560' post='4982271']
note that when moving, the camera is updated intermittently, and so the fps is alot lower than when stationary
Moving, or turning, is when a player is most sensitive to low FPS, so it can usually be a problem to use an algorithm that only do the computation when it is "needed". I think this may be a "worst case", which has to always give high enough FPS.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this