Hi,

I've been mulling over a few game designs for a number of years now whilst self learning the trade, as I'm sure we all do. I've recently boiled my current various designs down to a specific subset or genre if you will, and I've been developing the common framework technology behind them over the past few months.

All of my designs are going to follow a reasonably procedurally generated world and can optionally be infinite. I've got this part of the framework done and finished. For those interested the world is based on a point voxel system and I can successfully render any region of that world to polygons. This is more or less Minecraft at this point I suppose, however I don't really want to be one of those developers to clone it and apart from the most technical core of the design it'll be very different.
I'm currently working on a better way of rendering the world. I really don't want to rely on procedurally generated polygons - You can get anywhere from Minecraft style graphics up to pretty damn decent biological terrain using such a method but its very hit and miss and it constrains you to certain graphics styles. My other concern is that I want to apply this to a myriad of environments - Anything from forests and caves to spaceships interiors.

So, for the past week or two I've been toying with the idea of using just plain models to piece together a single voxel point and seamlessly interconnect with other voxel points. Should the concept prove viable it should allow me to be able to procedurally generate worlds at the voxel point level and have the world be rendered using 3D model 'tilesets'.

To do this I believe I need to make it as modular as possible. The modular system will only deal with the core environment - walls, doors, floors, roofs, stairs, etc. Anything like grass, trees, rocks, equipment, lights, etc can all come afterwards in another pass after the world has been generated.
I've put together a quick visual representation of what I mean by all this and the current design decisions I'm facing:
[media]http://i44.tinypic.com/9qbv48.jpg[/media]


I'm always a firm believer that if a solution is inherently complex it probably means you're doing it wrong, and I think that's what I'm doing here. I need ot find that sweet spot between having to create too many models for specific cases and too little transitional models between different voxel 'types'. Additionally, I'm looking for any technology I may not be aware of that could help.

Its at this point I'd like to request the input of the community. Happy to open-source this part of the project and/or write a blog on my experiences as a form of give back and incentive to help.

Just a quick note before anyone points this out: I'm not looking to generate say big rolling hills and forests right now. I know that specific topic is actually fairly well documented and viable to do.

Why not procedural generate the tiles as well? If you have a wall next to a floor, for example, you could start out with a ramp connecting the two from the midpoint of each surface, then run a noise algorithm over all 3 surfaces to roughen it up. You could tweak this for the various different types of environments, a cave would have rough surfaces where a starship would have smooth ones, for example.

You might also want to give the marching cubes algorithm a look (wikipedia page), it turns a set 3d points into a smooth mesh.

I think you are highly underestimating the complexity and hardware requirements of the "primitive" Minecraft. You are basicly trying to make a more detailed Minecraft with higher resolution of boxes, right? But the current Minecraft has trouble running on a high end 32bit system... I'm not sure if what you decribed is doable with current hardware level.

Start with data storage, for 100x100x100 area (a small one, Minecraft uses bigger) you need 1MB for boxes position only (no shading). How are you going to store and process it? How are you going to exclude boxes from rendering pipeline (that's 6 million polygons after you used culling to remove those not facing the camera)? These are critical questions, until you solve this worrying about "it looking better" is pointless.

Why not procedural generate the tiles as well? If you have a wall next to a floor, for example, you could start out with a ramp connecting the two from the midpoint of each surface, then run a noise algorithm over all 3 surfaces to roughen it up. You could tweak this for the various different types of environments, a cave would have rough surfaces where a starship would have smooth ones, for example.

You might also want to give the marching cubes algorithm a look (wikipedia page), it turns a set 3d points into a smooth mesh.

I've certainly thought long and hard about it. Here are some issues I've run into:
1. The resulting 'mesh' will require many different textures which will either require texture splatting tech or texture atlas tech. Texture atlas's suffer from limited texture resolution depending on number of textures. Texture splatting seemed like a good solution however the engine I'm using doesn't support it out of the box. I've no doubt that either of these methods could be made to work well, however I'm a dev by hobby and self taught. I'm not sure I could build up the time and expertise required to develop a solution around these methods without burning out.
2. I could procedurally generate a mesh per tile face, which would allow me to throw any amount of textures around, and I'm still open to this option. However I fear it won't provide the level of detail I would like. To do this I think I would need to supplement the tiles with additional model detail. For example a cave wall might randomly have a wooden pillar model in it, or a lamp. This could run into problems where the procedurally generated cave wall doesn't line up with the lamp - The lamp may end up inside the cave wall, or too far out. How could one mitigate that? I suppose you could raycast the wall and find the intersection point, and drop the lamp there. Its really not a bad idea and I'm open to that, but will I burn out trying to fix other corner cases like this that I'm not yet aware of? I don't know, I don't have the experience. Please feel free to offer your opinion.

I think you are highly underestimating the complexity and hardware requirements of the "primitive" Minecraft. You are basicly trying to make a more detailed Minecraft with higher resolution of boxes, right? But the current Minecraft has trouble running on a high end 32bit system... I'm not sure if what you decribed is doable with current hardware level.

Start with data storage, for 100x100x100 area (a small one, Minecraft uses bigger) you need 1MB for boxes position only (no shading). How are you going to store and process it? How are you going to exclude boxes from rendering pipeline (that's 6 million polygons after you used culling to remove those not facing the camera)? These are critical questions, until you solve this worrying about "it looking better" is pointless.

I'm fully aware of this. My data structure is streamable and compressible. The primitive model rendering code I've got right now renders only models within the view port. So I believe I've adequately mitigated this problem for the time being. I'm pretty sure I'll run into some bad memory leak issues at some point, but the concept should be able to scale infinitely (Note, I don't actually plan on allowing a world to expand infinitely as part of its featureset).
I'd also like to note that Minecraft's way of doing it is actually quite bad so I wouldn't put too much stock into how it does things.

Is it absolutely necessarily to have each cube cut up or could you get away with normal maps?

Is it absolutely necessarily to have each cube cut up or could you get away with normal maps?

Potentially, but isn't it the same problem anyway? Have to cut up the normal maps so they can tile.