Question

I want to create cube model of a 32×32 bitmap in opengl. For example, the result should look something like this given a 2D bitmap of Bob-omb from Super Mario: http://fc02.deviantart.net/fs49/f/2009/186/f/a/Bob_omb_in_Minecraft_by_Luafox.png The idea is to represent each 2D pixel from the bitmap as a 3D cube.

Each model will represent an enemy in a game so I need to be able to render these quickly. What would be a good way of doing this?

One attempt I’ve made is to generate a static 3D model from the bitmap by first creating a 32x32x2 grid of vertices and then creating triangles from these vertices in the appropriate places to form the cube faces. One big problem I’m having though is how to store the colors and normals for the faces. The triangles of each face need to share a vertex and that shared vertex needs to store the color and the normal for that face. However, I don’t think I have enough vertices for each face to have the appropriate color and normal. I can’t think of an elegant way to solve this.

Answer 1

Regarding storing colors and normals for the faces; I think you have to accept that you need to duplicate vertices in the same position for the different faces. If two vertices share some attributes but differ in others, they are essentially different – even if one attribute that they share is their position.

So, you should build some VBOs, with duplicate vertices as necessary. You may want to run this as a design-time step and save the results into a convenient format to save some work at runtime.

edit: That doesn’t mean that you need to have separate vertices for every single corner of every face of every cube. Actually, the cheapest way to render what you want (while the blocks are together) with a reasonably easy implementation would probably be to render the front and back each as two triangles, using a texture for colour, GL_MAG_FILTER, GL_NEAREST sampling and careful alignment of texture coordinates, using a pixel shader to clip on transparent texels.

You will then need to do a bit more work (not necessarily at run time) to work out which faces will be visible from the sides, and make each of those as geometry (all of that geometry being a single static VBO to display, thus reducing both the number of draw calls and geometry cost as compared to for example calling a -deprecated, although still often useful- display list for each cube). Again, with care you can ensure that this precisely joins with the invisible parts of the front and back faces.

If you do then want to have your enemies blow up and have the constituent cubes go their separate ways, you can then switch to a more expensive version displaying every single cube.