Questions about a voxel game

I’ve been recently looking into doing some game creation over the summer. I know that voxel worlds/games are a giant and imposing can of worms for those who are just starting, but who doesn’t like a challenge? :smiley: Anyways, I was wondering if there was a way to use a model created in Blender (lets just say its a cube for simplicity) as the block(s) that make up a world. I’m aware of the framework that needs to be in place to have such a game.

I was also wondering if it would be possible to use the system above to have different sizes of blocks, something like a class that draws an xyz value from a block type to create the collision box.

Thanks for any insight,
CM

Note: block worlds are not made of blocks. They are made of visible quads.

So … I can make my game of quads? Coooooool :slight_smile:

1 Like
@tirnithil said: So ... I can make my game of quads? Coooooool :)

1 Like

To explain more by what pspeed means by quads here is an image from my own block world. But I have messed with the quad formation so each quad is smaller than it should be so they don’t join up and you can see them individually.

Important points to note here:

  • The world is hollow
  • Only what is actually visible to the player is created
  • The back faces are not rendered so you can’t see the geometry “from the inside”

Why is this important

If you try to render every single block in your world you will have a bad day. For context my entire world with a render distance of 130 meters has 1 million verticies and I think that is too much. So lets take a 16 by 16 chunk of blocks and say its on average 60 blocks high. Thats 15,000 blocks right there. Each has 8 verticies so 120,000 verticies for a single chunk. So your render distance of 24 is going to get to 1 million verticies!

All in all you are asking the graphics card to render huge amounts of graphics that the player will never see.

You are also likely to want to create each chunk as a single object; in which case you may wish to look at custom meshes:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:custom_meshes

You are right to think that blockworlds are a challenge, but they are a lot of fun and there is plenty of room to make something different

Non full blocks

My algorithm for determinining if a side should be rendered is relatively simple; if a side is against air, or a non-full block then that side is rendered. For me Non full blocks are relatively rare so non full blocks are rendered all or nothing. If any of their sides are exposed the whole block is rendered

Trade offs

I know it doesn’t look like it; but box worlds are really at the cutting edge of what is possible, efficient code is key. This means that you’ll need to make trade offs, decide what you want in your game and what you can do without. The “sub blocks” you are describing would certainly be possible but would cost extra verticies and longer processing times to build the graphics; all this may mean a shorter render distance. Keep this in mind