FOSS gamedev and creative worlds

I totally love the idea of Minecraft / Minetest, but am not such a fan of block-made worlds. Nothing against them, but I prefer smooth terrains with real meshes in games. So I thought about a way in which this could perhaps be changed, for people who would like a Minecraft / Minetest with smooth realistic terrain (as an optional server setting). It's only an idea, and I'm not saying it needs to be this way, as I know it would be a rather major change.

To be clear: I'm not suggesting the terrain shouldn't be made out of blocks any more. That would likely be impossible and not wanted either. My idea only involves rendering it differently, and smoothing connected surfaces between the blocks to create round hills. So it would only be a rendering effect, with collisions also changing to reflect it. The system would stay the same, and everything would be virtually a block like now. It should also not confuse the player as to where he should look / point in order to dig, and make it obvious where each block is.

Obviously, the moment a block would be removed, the smooth terrain would get re-arranged and re-connected in that area instantly (since it's a dynamic effect in this case). But yes... the general thought is smoothing opposing corners of material blocks into a curved surface. I thought about using real meshes that could get melded together, but I think that would be rather hard and ugly.

There's also an image I quickly made, showing my idea better. Imagine that as a side view of a Minetest area, and each block being a normal terrain block. The blue lines are how rendering the surface would



I don't know if anyone else believes this would be a fun idea, but I believe it could be worth trying. I imagine that would look really cool both outside as well as in caves :) It would also be a feature Minecraft doesn't have. And with C++, it should probably not be too hard. What do you think?

Hmmm. I gave a bit more thought to this today, and took another look at how blocks are positioned. I think the only way this can properly be done in, is if some of the blocks are cut into, and have opposing edges rounded out instead.

This would be needed since in some cases, you would not be able to cover some corners properly with an outward surface. If you did, certain entrances would get blocked (such as one-block wide tunnels, which would require digging 2 blocks out instead). So I believe that my previous idea might need to be combined with this one. Here is an updated image of that I'm having in mind:



I'm still not sure how it would work, but I imagine some combination could achieve this. My example is not precisely how I believe it should work like, but just a raw estimation. Would like to hear thoughts and opinions on this.

sounds like a nice plan ^-^

sounds like very hard to code

Raillike grass, would that work?

Probably not.

Wanted to bump this thread since I'm still very interested in the idea, and had some new suggestions with the recent development.

Since the time I posted this, MineTest added its LUA API and games structure, which makes it possible to create your own game with the engine. I'm very interested in using MT to create games of my own with completely new items / blocks / mobs and ideas. However, I'm dreaming to eventually make some with full 3D models and without the blocky looks an low-res textures, in which I'd really want correct smooth terrain.

Here are some demos of something I wanted to do with OGRE (not mine) and might consider doing with the MT engine instead, in terms of terrain. Basically, I've been aiming for a while to make a game like MineCraft... but with smooth surfaces, high-poly 3D meshes for items, and the same mechanics and gameplay as MC / MT. Those videos are just for inspiration BTW, so I'm not suggesting it should look exactly like that. The words used in this case are marching cubes and metaballs.

http://www.youtube.com/watch?v=3hSVjqsXPOo

http://www.youtube.com/watch?v=7xTUvElNTj4

Anyway, the new suggestion I wanted to add is making smoothness a feature of certain blocks, and not a rendering option. This will allow people to make both blocky and non-blocky materials in custom games, plus properly calculate collisions so you can climb diagonal ramps for such blocks. Blocks with this feature enabled would merge with each other, while those without it would stay the same as now.

Another idea based on something I looked into recently; Bezier curves. I learned that those are an awesome way of doing this sort of thing, and generating smoothness based on spatial points. Neighboring blocks can use each others corners as points, and generate a bezier curve surface instead. A map editor for Quake called gtkRadiant (or netRadiant which is a fork still under development) allows exactly this under the name 'patch meshes'. Curves are probably not necessary though.

Oh, and something else I noticed: There's already a system to do something similar (but for another purpose) in MineTest, called farmesh. It causes distant blocks to connect and appear as continuous surfaces, in many cases diagonal ones. It's possible that code from there could be used and simply given a smoothness property. Also note that flowing water / lava do something similar already to block shapes, though again it's just one level of smoothness (a diagonal surface).

Especially with the custom games feature, I really support and would love to see this idea implemented, and really hope someone might try it in some form. If done as a block property, it might be possible to get by with a simple implementation (eg: the way fences deform to connect with each other, or the way flowing water deforms).

[EDIT] There's already something that does this for MineCraft. It's called MViewer. It has a feature for smooth terrain exactly like my suggestion. http://www.youtube.com/watch?v=Twat21yn6WY Also, another great example is the project Voxelaria. http://www.youtube.com/watch?v=4-4RlUARHLM

I've watched with interest your links.

What caught my attention was that the development of Voxelaria looks to be halted at the point when adding more features started to slow everything down. Did the author not find a solution for this. Why's this a problem with todays 'fast' and 'memory rich' computers? If you solve this slow rendering, lag, or however people call it, you'll might draw a lot of people to your planned game


Also MViewer, does that mean that it's only a way to view minecracft, not play it?

Topywo wrote:I've watched with interest your links.

What caught my attention was that the development of Voxelaria looks to be halted at the point when adding more features started to slow everything down. Did the author not find a solution for this. Why's this a problem with todays 'fast' and 'memory rich' computers? If you solve this slow rendering, lag, or however people call it, you'll might draw a lot of people to your planned game


Also MViewer, does that mean that it's only a way to view minecracft, not play it?

I just found out about Voxelaria (while googling about smooth terrain for MineCraft) so I don't know about its progress. Sad if it stalled, it looked really awesome. Same for MViewer... though from the video I got the impression it's just a viewer too (haven't seen anyone actually walking around with it). Either way, the smooth terrain in MViewer is a really fine example of precisely what I'm suggesting.

this coupled with bump mapping would be insane. good idea:-)

Death Dealer wrote:this coupled with bump mapping would be insane. good idea:-)

Imagine parallax mapping :D But bump / offset will probably be introduced much later on if anything. Still yes, it would be completely awesome.

while were on he subject a light shader like sonic unbeleavable shader would be nice to have with this also. and the reflective water^_^

Death Dealer wrote:while were on he subject a light shader like sonic unbeleavable shader would be nice to have with this also. and the reflective water^_^

Sure. They'd probably be different features though. Best way I heard would be to allow GLSL shaders to be added to a folder and run automatically. This terrain is a separate concern though, IMO more important than shaders for now (but I totally support those as well).

I was discussing this on IRC and someone posted something of relevance. Not sure if doable in MineTest, but still looks like an useful guide. The images represent what I'm thinking of quite accurately... just smoother (more subdisivions) and perhaps with texture blending between different block types.

http://www.volumesoffun.com/polyvox-about/

It looks cool but kind of messy. I like that idea, but not that intense.

maybe you could it make as mod, so people who like more blocky world can still use it

MirceaKitsune wrote:I was discussing this on IRC and someone posted something of relevance. Not sure if doable in MineTest, but still looks like an useful guide. The images represent what I'm thinking of quite accurately... just smoother (more subdisivions) and perhaps with texture blending between different block types.

http://www.volumesoffun.com/polyvox-about/

Very interesting in term of future abilities. :)

Stef wrote:maybe you could it make as mod, so people who like more blocky world can still use it

Yes. I'm suggesting this as a custom block property, so it's only done for certain materials that neighbor each other. For instance, natural stone would blend with itself, but cobblestone or bricks would stay blocks and not connect. The original game (minetest_game) doesn't need to use this feature either.

I'd really like to know if someone with more coding experience thinks they might attempt to implement this in some form. It doesn't need to be perfect, but the possibility of smooth terrain would allow for a lot of amazing things to be done *points to the image with the lake and trees*

First of all, I love this idea! Second, the renderer and the collision detector would have to change a LOT (plus a lot of server/client code changes). Third, a whole new modding API would have to be made.

My question is which line your character would follow. The contour, or the original block?

Rule of Least Surprise - Your avatar should do what would appear to be obvious to the player: Follow the contour.

theoriginalone wrote:My question is which line your character would follow. The contour, or the original block?

Clearly the countour, for a lot of reasons.

First is that the player would still appear as climbing a stair if collisions stayed blocks (bumping up with movement as he climbs each one) while in reality he's walking on a smooth surface.

Second, if the position of the player doesn't match the surface, his feet would either get buried into the ground or float above it.

Third, this would change the theoretical direction and shape. With blocks the player cannot walk forward unless he jumps (to climb 1 block)... but with slopes he would automatically climb as he walks forward. Without this he would have to jump to keep walking on a very small hill.

Of course, for the first part of the implementation, collisions could stay as they are till the smoothing algorithm is figured out. But before this could be final, collisions must match the slopes. Note however that the quality of the "collision mesh" can be much lower than that of the rendered surface, so maybe it can even be diagonal form while the slope is smooth / round (but it must represent its direction).

Here is a basic example of how (I think) collision geometry can be reduced for optimal performance in such cases. It also shows why the default (hidden) blocks cannot collide and the smooth surface must.

Here is another type of possible output.

Left: In the left panel you see the original terrain. At the middle of a node, lies it's center-points.
Middle: Now we make a grid through all center-points. Each blue square will get drawn separately.
Right: We will draw each blue square (corresponding to 4 center-points, or 8 in 3D). You can see each tile as some kind of tile.
This will give something like:

Inpsiration: http://books.google.com/books?id=WNfD2u8nIlIC&lpg=PR1&dq=game%20engine%20gems&pg=PA39#v=onepage&q&f=false
Some additional issues that I could think of:

• As this technique tries to closely follows the terrain I wouldn't change the collision system. It is only visual. However I might add a higher food-step-height
• The drawing may be dependent how much distance there is between you and the other nodes. Terrain who is near may have more detail
• Combining natural (stone, dirt) and artificial (brick) blocks may be difficult
• Smooth texture transitions are probably a must.
• Some items can be placed at a wall. (ladders, signs). Do they follow natural terrain? Are there new limitations where you can place them?

wokste: Very nice idea, I agree with that. If you plan to try coding it as well, cheers and can't wait to see what you get :D As for the points you mentioned:

• Trying to follow the original / blocky terrain surface is a great thing, as that keeps it easy to see what you dig. But I still believe collisions must follow the smoothing, for a main reason: With the normal blocks you have to jump in order to climb one node (unless you're pushing into a slab which you climb automatically like stairs). One aim in smoothing the terrain is allowing the player to walk seamlessly across the world, except when he runs into a hill taller than 2 blocks (at two blocks you might have to jump to climb up). So we'd likely have to increase step height at least for smooth blocks. This could also be fixed by spawning dirt / sand / stone in slabs naturally rather than full blocks, but that would be hard even if really useful.
• I think that would qualify as Level Of Detail. LOD is excellent and totally needed in such cases, so this likely wouldn't be an issue but a great thing. I do however suggest that the subdivision factor as well as LOD level is made configurable.
• That doesn't really seem like an issue. Like I said some blocks would smooth out but others would stay as they are. The trick with this is for the smooth block to treat any non-smooth neighbor as another node (so its surface is still bent according to it) but the normal block itself to not bend. I estimate that should still look ok for smooth blocks on the edges.
• I agree. Smooth terrain transitions should only happen between neighboring smooth blocks of different types (like between sand and stone) but not between a non-smooth block and smooth one (the case I spoke about in the paragraph above). For this, a one-block gradient type blending should hopefully be possible.
• That might indeed be a trick. Ladders and things placed on walls would likely need to stay square (not bend), but this could cause them to either get buried in the terrain surface or float away from it. Still, as long as one part of the ladder touches the surface and it doesn't look like the object itself is floating, it can be partly buried or left floating, since that likely wouldn't look bad. If not, we could restrict placing those on curved surfaces, and only allow it where the wall is flat (after 2 or more blocks in a row) which actually sounds like a better idea.

Anyway, here are some more images of similar projects attempting this. Not freebuild voxel + marching cubes terrain, but those using a similar block / node architecture to MineCraft / MineTest, since that's what we're working with. Also a video of another MC-like project which already seems to have this, apparently called Mine Wars. Its implementation is quite close to what I had in mind, only smoother in our case and without each corner of each block shifting.

http://www.youtube.com/watch?v=d6_ZaoCfK0o

I like the idea of smoothed terrain, trees, water, lava, etc.

BUT, keep in mind that "made" or "built" objects normally have sharp edges and perpendicular fronts. These should not be "smoothed", otherwise, buildings and mineshafts would look quite strange.

First of all, I don't have the plan of coding this.

Secondly I don't think the problems with combining natural and artificial blocks are fully understood. For understanding this I have created some pictures and the effect it will have.

This is the scenario. 3 blocks dirt, 3 blocks stone and 1 block of bricks.


For finding the correct 'tile', artificial blocks are treated as terrain. Additional dirt is placed at the side of the block. These types of additions can appear at stranger locations. (e.g. at the roof)


For finding the correct 'tile', artificial blocks are treated as air. I think this is a better solution since the terrain will not be modified when you place blocks.


A problem that can arise if we aren't careful is seeing the textures of normal blocks in terrain. (as part of the smoothing algorythm)

srothe wrote:I like the idea of smoothed terrain, trees, water, lava, etc.

BUT, keep in mind that "made" or "built" objects normally have sharp edges and perpendicular fronts. These should not be "smoothed", otherwise, buildings and mineshafts would look quite strange.

That's why I'm suggesting this to be a LUA flag for defined blocks. In my games I only plan to enable it for natural blocks... such as smooth stone, dirt / sand, and trees + leafs. But wooden planks, cobblestone / stone bricks, and other player-made blocks would not have it, otherwise houses would look all rounded and weird.

wokste: Posted my last reply before seeing yours. Sorry for the misunderstanding... hope someone else will give this a try then. Anyway, the output I had in mind and like the most from your examples is this one:



That feels most realistic to me, since it gives smooth blocks the feeling that they are aligning themselves with rough / normal geometry and properly blending. It's a lot like how you'd see terrain in real life for a house built on a slope. The stone / cement foundation is obviously flat and square, but it influences the position of the ground around itself. Also, the stone foundation is partly buried into the ground, since no house is simply placed there (the wind would blow it away lol).

Some random image examples. Not sure if the best but it might better show what I mean:





Either way, any of the ways you listed seem fine to me, so I wouldn't complain about either. The LUA flag for blocks could actually allow using any of the two options. I'm more worried that no one's ever wanna code this :(

I had an idea like this...