If you’re interested in the intricacies of game engine development, you should definitely keep track of Gavan Woolery’s Voxel Quest. The latest blog post deals with a whole bunch of new stuff implemented in the voxel-based engine.
The fact that VQ has undergone three tech revisions over two years probably seems a bit ridiculous, and maybe it is. Something like this would normally kill a game. That said, the point here is not just to make a game (plenty of people are doing that already), but to make a unique engine, and that could not happen in a vacuum. All I know is that I am finally happy with where the engine is at in terms of performance and flexibility, and I couldn’t have gotten here without knowing everything I’ve learned since the start.
So the most common question I get, of course, is how does this stuff work? It is actually simpler than it might seem.
Voxel Quest is more about developing a unique game engine than it is about developing a unique game, but its developer wants to release the engine as open source so that others can do cool stuff with it too.
The legend is here :
I like these articles. Computer graphics were the reason I became interested in CS.
Using a static cell size means there’s always going to be scenes for which the cell sizes are suboptimal. The static cell size approach is fundamentally unscalable.
Lets say the cell size is one cubic meter, and lets say the scene is of a desk with a phone, keyboard, mouse, speakers, papers, scissors, sea shells, junk, etc. you can end up with hundreds of thousands of surfaces per cubic meter. Having to test all these objects when a ray intersects the cell isn’t scalable. Therefor a cubic centimeter may be more appropriate.
Now lets say the cell size is one cubic centimeter and the scene is a mountain vista, visibility at 5kilometers away. Every ray will have to traverse 500k empty cells before hitting something. It is not scalable either.
Game engines can just limit the render distance, adding fog or some artificial skyline, but that’s kind of lame and doesn’t help with even more extreme scenarios like outer space.
So, for these reasons I’m actually predicting another revision will be necessary. The BSP trees of quake fame could easily handle arbitrarily sized objects with arbitrary space partitioning. That could work very well here, yielding optimal cells for every scene. It would generally work best with static scenes that could be precomputed since building the tree is an intensive operation.
Another approach would be just to use recursive cells. If a cubic kilometer contains nothing, then the engine can just skip all that space and immediately move on to the next kilometer. Once it finds an occupied cell, it can break down the cell size and search using smaller cells, those cells can further get broken down. This way the engine knows that each and every cell it processes will be occupied, while simultaneously allowing the engine to place a ceiling on the number of objects to test per cell.
This allows large scales and small scales to coexist, such as having the desk in the foreground and a window view of a mountain vista in the background. The rays would traverse small cells near the desk, but would traverse huge cells in the empty space outside.
How I miss this still, back to work now.