Jump to content
  • Advertisement
Sign in to follow this  

What culling method would be best for cube land?

This topic is 2125 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...!): http://codeflow.org/entries/2010/dec/09/minecraft-like-rendering-experiments-in-opengl-4/

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
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
The way I do it:

  1. Group blocks into chunks.
  2. Pre-compute list of visible surfaces for every chunk. That is, faces from blocks that are adjacent to "air" or whatever.
  3. Cull chunks that are outside of the view frustum.
  4. Sort the chunks in order from near to far.
  5. Define bounding box for each chunk.
  6. 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.

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
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!