Rendering dynamic uniform cube grid

Started by newobj, September 09, 2012, 16:35:34

Previous topic - Next topic


I was playing around with implementing something like Voxatron's engine ( in OpenGL - Voxatron uses a software renderer. It's essentially just a uniform grid of cubes, which are either on or off, and each have a color. The challenge here is the dynamism of the rendering - because it's software it's basically the same price to render a static scene versus a scene where almost all the cubes are changing (appearing/disappearing/changing color) from frame to frame, so it's used to great effect - explosions etc look awesome.

So I was wondering what'd be the best (fastest) way to do this with modern (but not cutting edge, e.g. tessellation) OpenGL - e.g. perhaps a solution that would also work with ES.

My first thought was to create a VBO with all points of the grid, and then feed in a new index buffer + color buffer every frame. And I suppose normal buffer, too. This seems like it's going to be very slow - seems like a lot of data to be pushing around. If I wanted to support a 128x32x128 voxel viewport, that's 500k cubes, and assuming maybe 25% of them were turned on per frame, that's 125k cubes, assume 2 faces visible on average, 250k faces, 4 points per face, 1,000,000 points, plus color, plus normals, etc. It just seems like a lot, but I haven't done any rendering coding in a long time, so maybe this is actually totally reasonable nowadays.

So basically I want to "rasterize" a uniform 128x32x128 grid of colored cubes every frame. What's the best approach?

Thanks much!

Darth Revan

1,000,000 Cubes are no problem. Cut them in Chunks of 16x16x16 Cubes. At the beginning you make a VBO for each of them and than you only rebuild the VBOs of the Chunks that changed. To make the data that will transfer to the VRAM/GPU smaller you can calculate what faces are visible and only put that in the VBO.

PS: Sorry for me bad English.


Hmmm... I'm not sure if that is actually suitable. In voxatron, the cube field changes every single frame, and I don't know if updating a direct VBO is the best bet.

For example, storing just the points in the VBO might be better, and you could use some sort of geometry shader to turn each point into a cube when rendered. That way, you have a much reduced amount of data in the VBO and are more capable of updating it.

I don't have much experience with geometry shaders, however, so I'm not 100% sure about that.