Infinite Minecraft-esque terrain
Community Forums/Showcase/Infinite Minecraft-esque terrain
| ||
I've been working on voxel based terrain generation lately and wrote a small demo in BMax showing a few features. The algorithm is based mostly on perlin noise combined with its ridged version to create complex terrain and caves. Fortunately, the perlin noise approach doesn't constrict the size of the landscape, making it possible to generate infinitely big landscapes (until you run out of floating point precision, that is). To render the whole thing I also started writing a small 3D engine in BMax based on OpenGL (called "ZauberCraft"). It is definitely not intended as an alternative for any other engines out there; it is being programmed with Minecraft in mind and won't be useful for much else. The demo consists of a flythrough of the generated world. New parts of the map get generated as the camera reaches the borders of the currently visible area (more or less fluently, depending on your hardware). Download demo (Exe + BMax code): Link Everything is still work in progress right now, so crashes may occur. When building from source, make sure to have debug disabled and threaded build enabled. Last edited 2011 |
| ||
| Do I smell an SSAO going on? Looks terrific. |
| ||
| very impressive, but very jerky too. I'd upvote if i could. |
| ||
| Very good :) |
| ||
| Awsome :) |
| ||
| Very nice. camera seems a little out of sync with terrain generation. After a while the terrain is moving further and further away into the distance. Last edited 2011 |
| ||
| Looks absolute quality my friend! I need a Mac version sharpish to play with. I don't expect to see you wasting time chatting to your friends on here until it's done. ;) |
| ||
| How does the terrain generator/engine work? |
| ||
| i was going to ask similar. Can you give an overview of the rendering technique? |
| ||
| Good demo Bit jerky on my setup (below... Tried it on Bootcamp WinXP SP3)... Voxels, they are lovely things, but I get the impression the world isnt quite ready for them yet! ;) Dabz Last edited 2011 |
| ||
| Really....this is quite impressive. Thanks for sharing the source as well!! |
| ||
| Is there some method for 'smoothing' these voxel landscapes...I'm thinking similar to a resampling technique for 2d images, some sort of method for interpolating between cubes to generate a more rounded appearance? |
| ||
| Matty - there's marching cubes, but it's slow (and patented, if you believe in such things) |
| ||
| Quite impressive! |
| ||
| there's marching cubes, but it's slow (and patented, if you believe in such things) The marching cubes patent is supposedly now expired as of 2005: http://en.wikipedia.org/wiki/Marching_cubes |
| ||
| I need a Mac version sharpish to play with. I don't expect to see you wasting time chatting to your friends on here until it's done. ;) It is cross-platform, you just need to find a nice person to compile it for you. I only own windows, sorry :) As for the time wasting part... whooops! How does the terrain generator/engine work? i was going to ask similar. Can you give an overview of the rendering technique? Rendering itself is really not that special - plain old polygon rendering. I thought about using a sparse voxel octree implementation I did in BMax a while back, but that one didn't support colors, so it wouldn't look all that good. Terrain generation, on the other hand, is a bit more complicated. What it all comes down to is lots and lots of Perlin noise. What you start with is one basic Perlin noise function. You map its output to an interval of [0, 1] and get something like this:  Since we want air at the top and blocks at the bottom, we have to introduce a gradient that goes from top to bottom that represents how likely a filled block at a certain height is:  Then we just add those two, apply a threshold and *drumroll* get basic terrain!  Since caves are also very nice, we take another Perlin noise function, take the absolute value of it (remember: Perlin noise always lies between -1 and 1) and substract it from one. So basically: Cave = 1.0 - Abs(PerlinNoise(X, Y, Z)). Then we get something like this:  We then apply a threshold so only the places with high values get recognized as caves:  These caves are still a bit boring. One way to solve it is to take three new Perlin noise functions (one for each axis: X, Y, Z) and perturb the caves with them. What I mean by this is: If we want to look up whether Voxel (X, Y, Z) is a cave, we add the three aforementioned Perlin noise functions and actually look up voxel (X + PerturbanceNoiseX, Y + PerturbanceNoiseY, Z + PerturbanceNoiseZ). This results in nice labyrinthine caves:  Finally, we multiply the cave and the terrain image and get our result:  Implementing minerals or different layers of blocks isn't too difficult from here. It's just more Perlin noise functions added into the terrain generation function. And just to clarify: By "new Perlin noise function" I just mean regular Perlin noise with a different random seed. It is of course still the same function, just with different results. Thanks for sharing the source as well!! I always try to include the source code when releasing something. I profited (is that how you spell it?) from other people's codes so many times in the past, it would be naughty not to give something back :) Is there some method for 'smoothing' these voxel landscapes...I'm thinking similar to a resampling technique for 2d images, some sort of method for interpolating between cubes to generate a more rounded appearance? I don't think that would look good with the terrain as it is right now. The problem is that the generation algorithm doesn't calculate smooth values, but only "1" (block at this position is filled) or "0" (block at this position is empty). I guess you could divide a block into subblocks, calculate which subblocks are filled and which ones aren't and then average these values to get a more accurate value for the parent block, but that would get really slow (and then there's the marching cubes overhead on top of that). Thanks for the feedback, all of you! Really appreciate it. |
| ||
| Sadly it constantly hangs, scrolls for a few secs and then its calculating for quite a long time, we must repeat. |
| ||
| Unfortunately, terrain generation is quite computationally expensive. If your computer isn't fast enough to generate chunks as fast as the camera moves, the program will wait up so the terrain doesn't disappear out of view. This results in "hangs", where the camera won't move any further until the worker threads have finished (the main thread is still running though, so you can still turn the camera). |
| ||
| This is really awesome. |
| ||
| dubble bubble Last edited 2011 |
| ||
| @Noobody I have no idea about what's going on calculation wise in yours (too much for my i5) but i'm coming from such examples (which my i5 handles with ease). It needs the plugin from the cheaters and for performance reasons you better go fullscreen. ;O) Last edited 2011 Last edited 2011 |
| ||
| Ah, source included. Very generous, sir. I can mail you a MacOs build if interested. |
| ||
| but i'm coming from such examples (which my i5 handles with ease). When it's actually generating the chunks (i.e. at the beginning), it freezes up and almost crashed my Firefox. From then on it renders the landscape, but doesn't generate new parts of the map - you can actually walk to the end of the world and fall off :) So, it's not really a comparison. I'm not saying that my program is better than the one you linked to - far from that. It's just not the same thing. I can mail you a MacOs build if interested. Yes, that would be great! Thanks a lot. |
| ||
| Yep, i wasn't aiming at this code is better than yours. I just found yours a little bit impracticable as i (MacBook Pro) had to wait 7-8 seconds for each update, more as the generated areas are so close to each other and these updates hit you every few seconds. The Unity example does initialisation during startup (same 100% CPU hogging as yours with BlitzMax) which takes about 10 seconds (yours took about a minute) but then you can move around in a rather larger area already without any recalcs. That's what i found more practicable. Last edited 2011 |
| ||
| Well, trying to demonstrate infinite terrain generation with a finite static terrain seems like missing the point to me. But let's not delve into this argument any further - you've made your point clear, and I see this thread in danger of derailing into a Unity-related argument. |
| ||
| Well, imho and from an endusers point of view a, technique which generates new chunks of data with such delays does seem to miss the point much more. Btw the terrain in the example i've shown is a) generated in a similar way and b) you can dig holes through it. What's the non static nature of yours? Last edited 2011 |
| ||
| 'enduser point of view'? It's a code example, mate. Thanks for sharing, Noobody, it's educational and cool at the same time :) |
| ||
| It's called feedback, although some prefer getting none instead of honest ones. |
| ||
| I'm not in the mood for this, you win. |
| ||
| I'm glad you weren't because i wasn't too. :O) |
| ||
| Shame, it doesn't seem to run on my Mac. The app starts, I get the spinning egg-timer replacement for 60 seconds and then I stopped it. Tried that a couple of times. Any Mac owners have more luck? |
| ||
| Noobody, have you done any work using the marching cubes algorithm? That seems like the next logical step for this. |
| ||
| @John Galt You need patience, the initialisation takes a lot of time, a minute on my i5 2.5Ghz. But if your computer takes even more than don't hold your breath for it because later on you won't see a lot because it will constantly recalc and for 3 seconds of animation it hangs 7-8 seconds. Last edited 2011 |
| ||
| @John Galt and taumel: Did you read the note at the end of my post? When building from source, make sure to have debug disabled and threaded build enabled. It will compile in non-threaded mode as well, but then of course terrain generation will halt the main program. @JoshK: Back in B3D, yes. Download (German) |
| ||
| Yup, debug was already disabled. Building a threaded app resulted into a crashing app, so only one thread here. |
| ||
| It ran fast on my 3.31 ghz dual core. No delays at all. @JoshK: Back in B3D, yes. Download (German) Nice job! Last edited 2011 |
| ||
| This is very cool. And source available too. |
| ||
| No, just can't get it to work. With threading and including GUI (not sure if this was required?) it gets an unexpected quit. With threading only, it compiles then says process finished, no display. |
| ||
| @John Galt & taumel: Very strange. It shouldn't be a problem with OSX itself, as a friend of mine owns a Mac that runs the code just fine. I guess I just suck at programming :) I'll try to look through the code and find the problem, but it's a bit hard to narrow the search down as the error doesn't occur on my machine. |
| ||
| Thanks a lot mate, I would like to see that demo run! |
| ||
| I'm curious, how did you handle the logic in your marching cubes algorithm? There's something like 255 possible configurations for each voxel. Did you look for the base 15 cases and then flip and rotate, or does your code actually have 255 branches of logic? |
| ||
| @JoshK: I dropped you an email with more details, but I basically precalculated two lookup tables for all possible cases, which I could then use at runtime with no performance penalty or spaghetti code. |
| ||
| I want to make a C++ version of this! Alone replacing all float with double would give a 5 times speed increase in C++, plus it would support much bigger terrains then I guess, if the float limit is active. And maybe it would be fast enough even with smaller cubes, 4 times smaller cubes would already look quite smooth from far. Last edited 2011 |
| ||
| @Noobody, I can assure you, you do not suck at programming, great showcase! |
   |