Here at RTR HQ we like to consider ourselves trailing edge, covering all the stories that have already been slashdotted and boingboinged, not to mention Penny Arcaded. My last post included the simulated 6502 project. The madness/brilliance of this ALU simulator boggles my mind. Yes, Minecraft is awesome, and for the low low price of $13.30 it’s had me in its terrible grasp for the past week, e.g. this.
I wanted to run through a few graphical bits about it. First, the voxel display engine is surprisingly fast for something that runs in the browser. Minecraft uses the Lightweight Java Game Library to drive OpenGL. Max McGuire figures that the program tracks the visible faces, i.e. all those between air and non-air, and then brute-force displays all these faces (using backface culling) within a given distance. The file format keeps track of 16x16x128 (high) chunks, so just the nearby chunks need display. I don’t know if the program’s using frustum culling on the chunks (I’d hope so!). Looks like no occlusion culling is done currently. The lighting model is interesting and nicely done, we haven’t quite figured it out; the game’s author, “Notch” (Markus Persson), notes that it was one of the trickier elements to make work efficiently.
Me, I’ve been looking at voxelization programs out there, to see if there’s a good one for turning models into voxel building plans (it’s a sickness, seriously). Patrick Min’s binvox (paired with his viewvox viewer) looks promising, since Patrick’s a good programmer (e.g., his CalcuDoku app), the program’s been around 6 years, and it’s open-source. Binvox uses the GPU to generate the voxel views, so it’s quite fast. It supports both parity counting and “carving”, and can also remove fully-interior voxels after processing. Parity count is for “watertight” models (closed and manifold, i.e. the polygon mesh correctly defines a solid object without gaps or self-intersections, etc.). Carving is taking 6 views and recording the closest occupied voxel from each direction. It won’t give you holes or crevices you can’t see from the 6 directions, but is otherwise good for polygonal models that are just surfaces, i.e., that don’t properly represent solids. See his page for references to all techniques he uses. I found a bug in Patrick’s OBJ reader yesterday and he fixed it overnight (fast service!), so I’m game to give it another go tonight.
You can witness the lack of occlusion culling and the visible face tracing by performing a texture hack. Simply extract minecraft.jar and add some transparency to the textures in terrain.png, then repack in zip format.
What irks me is that the set of blocks that are considered transparent is hard-coded. Replacing the dirt texture with the glass texture does not create an equivalent rendering to that of replacing dirt tiles with actual glass.
My experience with binvox was that it had issues in at least one case with some very thin & sharp features — missing a surface caused it to generate strands of garbage geometry. But aside from that it is pretty nice.
> My experience with binvox was that it had issues in at least one case
> with some very thin & sharp features — missing a surface caused it to
> generate strands of garbage geometry.
Absolutely: because binvox renders a model at the resolution you specify
(it defaults to 256×256), anything that doesn’t render at that resolution
will not end up in the resulting voxel model.
A trick is to render at a higher resolution and then downsample, for example:
binvox -d 512 -down my_mesh.obj
Also, for some models using just the “carving” method works best:
binvox -c my_mesh.obj
I’ve put up a page describing the process at:
http://www.patrickmin.com/minecraft/
(work in progress, comments welcome)
Patrick
It looks like it does frustum culling. The frame rate rises and falls depending on where you’re looking. Especially at the edge of the world: when looking inside the world, the frame rate is much higher than when looking outside.