Discussion in 'General Discussion' started by jc_lvngstn, Oct 8, 2010.
realtime debugging is possible within some boundaries - u3 + monodevelop
I haven't had much luck with this, maybe I was doing it wrong. I did try it for quite a bit.
Honestly, I could debug the non-unity code, with some unit testing...I've just been lazy in that regard. It would have saved me grief, tho. Just gotta do it I guess.
Forgot to mention in my previous post with my current code...press T to turn a block into a fully light block of air. Insta torch.
cool guys, pretty close, but I think plane copying is not smart
Check this guy, http://forum.unity3d.com/threads/65602-WIP-Whirlpool-Arena-Pirates-and-Ship-Battle-Building-Game
I think this is better way to push the minecraft idea further
That screenshot looks cool!
Yes i think whirlpool looks quite cool but i wouldn't play ist, just because im not interested in a game like that.
I don't want to copy minecraft 1:1, just like notch got inspired by infiniminer, i got inspired by minecraft and want to go a slightly different road. But i don't want to talk too much about it yet
I just want the terrain system to work 100% before i go on adding my stuff, and of course the terrain system will eventually be very close to the one from minecraft. Why would you want to invent the wheel over and over again?
The problem about this "copy minecraft" topic is that minecraft is a kinda new game approach, there are not many games like this (at least not many popular ones). I know infiniminer, dwarf fortress and Roblox, they are all quite simliar.
But i bet if super mario came out, and people tried to make their own Jump n Run game, they got this "boo you are copying super mario" stuff too. Same for shooters, RPGs, MMOs, etc.
It just has no real genre so people keep saying "im doing a minecraft game".
I kinda want to do an Lets Play of minecraft too (there are many good ones already though) but i don't know, i somehow wanna do it in english but i'm not a native english person (im german) so this might be not a good idea lol.
My goal with all of this is not to copy minecraft. I'll end up with my own unique game. The only thing it will likely have in common with minecraft is that it creates a procedural world, with caves and such. But I'm not interested in copying minecraft...only some elements of it. Just like every single game out here you've probably ever played.
Every since Wolfenstein 3d (and it actually came from earlier games), all the way through Doom and Crysis, those games have "copied" and built on the ideas of previous games.
I don't see this as any different. A lot of it is a learning experience for me,it's been incredibly satisfying figuring some of this stuff out.
The other reason I am doing this is to give to the community. Every now and then, I provide the FULL source package in Unity for my current progress. From now on, if anyone ever asks "hey, anyone know how to do lighting like minecraft, or terrain generation?", they can look at my examples. I purposely wrote the code in such as way as to be easy to follow and understand. At the point I start putting in my own, unique ideas...I probably won't release that source.
So, I want to provide a "Minecraft Template" for people to build their own, unique ideas in the future. I don't think anyone really wants to make a duplicate of minecraft. They want to add their own cool stuff.
I saw that building game idea. It's awesome...but not my own unique idea(s), which I don't recall sharing anywhere. So...give me a chance to show my own cool stuff eh?
JC, I thank you for your posts... it is great, great information!
I've never played it, nor do I really want to, but Minecraft appears to be nothing more than a rip-off of Dwarf Fortress with some fancy terrain gen and retro graphics. I assume it went into production right about the time the marching cubes patent expired, right?
No it's not a ripoff, you should just try it out or go to youtube and watch some Lets Play of it (i recommand Coestar or davidangel64 aka X) to get overview about that game
And i don't think it has anything to do with the marching cube patent, cause he isn't really using any marching cubes.
well guys I did not want to hurt anybody saying copy. I see no bad meaning in this word, so if you do you got me wrong.
The mine craft concept is as old as Lego and even that is just an enhancement of wooden blocks with "living aspects"
Think about what MineCraft really is:
builds a world out of blocks, objects combined from blocks, all looks blocky -> Lego
None the less its a rather fresh approach to the take, one thats definitely appealing even in graphics that technically wouldn't require more than a SNES / GC to run if it were done through real acceleration etc and I personally hope to see more sandbox type games again, as they vanished the past year for "5 hours of high end graphics fun with a story thats even more shallow than hollywood trash"
Yes of course the building aspect is nothing new in general, it's just lego, making sandcastles, whatever.
I just meant it's something new for the gaming genre (the whole infinite world, build whatever you want thing).
But i bet that's the reason why it's so addictive to some people, including me, cause you get this childhood lego feeling back, which was awesome. Or building castles out of chairs and pillows/blankets
I want to increase the graphics resolution a bit, higher texture sizes and maybe some basic shaders (like bloom, just because i love it) but i won't use it for any gameplay aspect so you can simply turn it off if you don't like it.
I also don't want to have everything made out of pixels, except for the world. I prefer using lowpoly objects with a nice texturing like Kingdom Hearts/WoW/Pocket Legends, to make it more appealing.
It is, in fact, a rip off of Dwarf Fortress. A friend plays Minecraft relentlessly and every feature he's reeled off has already been done in DF. The problem is, Dwarf Fortress is an ASCII (or tile-based, if you prefer) game with a ridiculous learning curve, with a relatively tiny market appeal. You'd have to spend days reading the wiki just to figure out the menus, never mind the game concepts.
DF generates massive procedural worlds complete with biomes, civilisations with thousand-year histories, wildlife, etc, and you can choose a place in the world to build an underground (or above ground) colony by mining out ASCII blocks or building structures and machinery. Every single character in that map up there is a large playable game area spanning several screens, and about 100 layers deep.
The world is essential several hundred layers of 2d arrays like Minecraft, with different types of rock and soil, complete with huge underground caves full of creatures and a portal to "hell" somewhere full of horrible tentacled beasties. People have written 3d visualisers for the ASCII world, and guess what it looks like? Go on Google Images for "Dwarf Fortress" or "Dwarf Fortress 3d" to see what I mean.
The guy behind DF is a true mad genius, and has been working on it for years adding all sorts of insane features. He scrapes a living out of donations from the forum, and while there's no doubting the effort that went into Minecraft it is quite clearly just Dwarf Fortress with added grinding to appeal to people who like that sort of thing.
Sorry for derailing the thread. There's some truly impressive work going on in here, and I love sandbox/random/procedural games of any kind. I've spent countless years playing roguelikes (Dungeon Crawl, mostly) and will never tire of them despite the simple tile-based or ASCII graphics. They pack more replayability than any big-budget console release, which tend to get shelved after 8 hours unless they have multiplayer, and you can only pwn so many loud-mouthed american kids in Call of Duty before it gets old.
I should probably add something a bit more useful to the thread than the above rant, so maybe this might inspire people:
While developing a procedural world generator years ago, I used a series of libNoise nodes to generate a huge 2d array of elevation values, then rendered those as tile graphics. Low elevations got a water tile, then sand, then grass, then mountains, etc. After a post-processing pass to swap in some rounded edges on things like coastlines, it gave me a massive NES Zelda-like world to wander around in. After getting into 3d engines I realised that what I basically had was a heightmap and that I could now render all that as a terrain instead.
If people really want to generate monstrous worlds, then you definitely want to check out libnoise and think about hooking that up to the Minecraft-rendering wizardry that's going on in this thread, as it gives much better control and results than plain Perlin or Simplex alone. It's comparable to having something like Terragen embedded in your world generation code.
I ported chunks of libnoise to C# for my terrains. If I get the time I'll likely finish the port and post it.
A c# version would be very cool, I was just going to compile it into a .dll and try playing with it from there. I've also used cellular automata in the past to generate connected caves, although I'm unsure how or if that would apply to the 3d stuff going on in here.
They're pretty closely related. CA is how I would do fire, water, possibly terrain shifts (ie slumping). The voxels are more or less the 'cellular' part of CA.
That looks awesome
Maybe I'll learn more about shading, so that the fog actually gets darker underground, instead of lighting like it does above I've had to remove it because of that effect.
Na I like the lighting It makes it feel like you are on an epic sized floating island or something
Here's some more:
Very nice! Your generator's really coming along
Man I wish I had more time for this right now. Stick with the colossal features, I love 'em.
@jc_lvngstn: Very cool!
On a side note, looking for some suggestions on how to tackle a couple of issues:
1. For the most part, the lighting works. But, let's say I have a chunk that is lit, and right beside it a chunk that has an overhang. So chunk 2 has some dark places beneath it.
When my terrain generator first runs, it processes all chunks and for each block in the chunks it assigns a fully lit or dark value.
The mesh generator comes along, and processes each chunk. What's happening here is, the mesh generator (which also handles lighting) only looks at the current block's lighting as correct, and changes the lighting of blocks around it based on its lighting. So looking at the dark blocks, it doesn't change the dark blocks based on the light blocks in the chunk next to it. Not sure if that makes sense.
So, it either needs to change the current block's lighting based on lighting around it, or I need three stages instead of just two: Generate terrain, generate lighting, generate mesh data.
The lighting stage would process the entire map when the game starts, and later during gameplay it would only process new chunks as they are added when the player moves.
Any thoughts on this?
2. I'm running into issues where I think my chunk meshes have too many vertices. So I can either a) have chunks with more than one mesh, or b) I can switch from having chunks that are 16x16x128 blocks and do something like 32x32x32 instead.
I like the idea of b, even though it may not be as efficient, just because it is more straightforward and allows for a lot more flexibility. It's just a little more straightforward in the code I think, not having this weird chunk size of 128 blocks deep. Granted, memory use is still an issue. Even using a struct for my block data of two bytes, a 512x512x128 world of blocks takes up about 670 megs!
3. Which brings me to my other issue...gosh, memory. It's not a BIG issue yet...but I'm trying to keep it in mind.
One of the things I can do is, anytime I generate a chunk's fully lit mesh, I can discard the block array of data. The idea behind this is, once I generate the mesh...there really isn't any need to keep all of the information on the blocks in memory. Right now, a 512x512x128 map has 256 chunks in it. If I only were to keep say...10 chunks in memory of 32x32x128 blocks each, and save off the rest...that shrinks my block memory usage down to about 2.6 megs!! That's huge!
The initial world, and any new chunks that move into view would be generated and saved to disk. Only the chunk the player was currently on, and those immediately around him would actually contain block data. That's 9 chunks of data.
Granted...a lot of this depends on what gameplay elements are present. If you had a game that had a lot of dynamic terrain changing going on (let's say it rained bombs that blew holes in the ground), this probably wouldn't work. Any creatures and such that move around in the world would have to be kept in lists, and would solely depend on collision with the mesh. This presents a problem if they walk into a block of water or fire. I could give each chunk a list of dynamic blocks like water/fire, and have the creatures check against that. It would work, but at this point I feel like it's starting to get messy, even thought it would still use less memory than keeping a fully array of block data.
But, the possibility of drastically cutting down on memory usage sure is tempting.
So...easy approach is to just keep block data in memory for the whole world, possibly limiting gameplay (world size and complexity) in the future, or shoot for less memory use and a more complex overall design which still might not fit some gameplay needs. Remember, I'm trying to provide a starter package of sorts. Maybe that's the problem right now...I'm generating pretty complex terrains, when I probably should back off, provide initial, simple terrains...and let people make their own decisions for the custom/complex stuff.
You might want to consider using an octree to represent the blocks. Only the blocks exposed at the surface need be represented in full detail. Other clumps of blocks that are completely enclosed can be handled in bulk until they are eventually uncovered.
How would this work with the blocks having a variety of types? It seems to me that an octree is about consolidation, but I am likely wrong on that
Would the octree be limited to only blocks that are of a certain type, and exposed to the surface?
Here's more screenshots. Not trying to overwhelm the forum database, somebody let me know if I need to ease up
That looks very cool. Very alien.
Was playing some Minecraft yesterday and discovered a massive cave system with long, narrow paths and huge open rooms with lava and water flowing through them. If everything is random he's sure doing a great job with it.
That's looking really awesome. Love where these projects are headed.
The basic idea is that you only need to subdivide a given node of the octree if its elements are not all of the same type. It is often used with binary data (implying simple inclusion/exclusion) but you could make the "payload" of each terminal node anything you like. I'm assuming that you tend to have contiguous regions of different materials rather than a completely random scattering so this might be an efficient way to store the blocks. Even if there is a lot of noise in the landscape, I would think you would save some memory overall just by reducing storage for the empty space.
The screenshots are looking AMAZING Jc! Keep up the good work, that's awesome. I have been messing around with your (I believe its yours) code that you posted but haven't made many changes on the terrain since you have been doing a great job of it. I have been using it as a placeholder for the terrain while I work on other aspects of a Minecraft/Dwarf Fortress/Something completely different from either game I am thinking about.
Where in Beezirs code is the bit that chooses where the blocks go
Thanks for the encouragement, all.
Andeeee, right now we have to check neighboring blocks quickly, for a variety of reason...lighting being one of the main reasons.
Would octrees be a good choice for this?
When I create a big enough world I run out of memory and I get this horrible "to many heap sections" error/bug.
jc, You say that the memory problem can be solved by discarding the block array of data. How would this work? And would the free memory somehow speed up the mesh generation?
I tried to put in "m_ChunkData = null;" after the mesh generation but nothing really happened.
Another little thing I'm fighting with is changing the size of the blocks, for example to 1.5, 2 oder 2.5 or something like that.
Scaling the whole thing afterwards leads to an 5-10 seconds freeze of my system ^^
Anyway, cool work guys =)
So, something I probably need to do is test this in a virtual machine with less memory allocated. My machine at home is running Windows 7 64 bit, 6 gigs of memory, and is a quad core. For all I know, my crap doesn't run on a lot of people's machines.
The main reason to keep the array of blocks in memory, for each chunk, is for lighting. The noise function isn't quick enough to do the lighting on the fly. Now..this is just my opinion. I haven't actually benchmarked how much slower it would be to just dump the block array of data and only use the noise function.
The stuff I have now takes advantage of multiple cores. On a fast computer, you probably could have the game just retrieve the noise values all the time, instead of storing them in a block array. It would use a lot less memory, but it would probably run like crap on a slower, single core machine.
Honestly, I think a hybrid approach might be best, where you keep the block data for the chunks around the player, and ditch the other ones. Or, if I had more experience, look at an octree implementation like Andeeee talked about.
Oh, and as far as block size...you could just change the code that creates a block side (I forget what the method is, CreateBlockSide or something like that in the MeshGenerator) to be x+2, y+2 etc instead of x+1, y+1...the only problem is, other parts of the code expect blocks to be 1 unit. When chunks are placed, if a chunk is 32 blocks wide, the next chunk beside it gets placed at x+32...if that makes sense. If your blocks were 2 units wide, you would have to place the next chunk mesh at x+64.
Unless you reaaaaly need your blocks to be different sizes, you just scale down your player maybe..make him .5 unites tall or something.
Otherwise, you're going to have to change more to the code than just the mesh creation.
If you really need that, I could probably fit that in there to where you could specify the actual size of blocks, and have it automatically figure out where to place stuff I'd be happy to do that...for some better textures or something
Freeing the memory wouldn't necessarily speed up the mesh creation, unless most of the memory has already been gobbled up and your whole system has slowed to a crawl. If anything, keeping the block data in memory makes mesh creation faster, it doesn't have to call the noise function for each block's data, it just pulls it out of the block array in each chunk.
Thanks for your detailed answer =D
The hybrid approach might work very well, but yea, keeping all the block data in place and save memory with this octree sounds certainly tempting! The question is, it's possible to implement the octree fairly easy or would it be as cryptic as the word looks like?
Ahh, yes I see, that made the trick. Setting the chunk distance to for example 64 instead of 32 shouldn't be hard either, thanks!
looking good, post more screenshots and bigger ones, if its not too hard make a video, your terrain generation loooks more interesting then what notch has done so far. More epic and fantasy like perhaps I'm waiting for more screenshots!
For anyone looking at my source, I'd appreciate any suggestions on how to improve the documentation. Keep in mind that when I release the "starter" package, I do plan on having a design document explaining how/why it works. It should cover everything from the threading to mesh generation, etc.
I don't think Unity is going to be using more than 4gb or RAM, if that, as it's not a 64 bit app.
When I ran into memory issues it had more to do with meshes than the voxels. With a chunk size of 16x16x128 and a world of 32x32 chunks, the voxels only take up 64 megs of ram.
The way I do it keeps the voxel ram usage constant and accessing any voxel is done in constant time (using array indices). The meshes are what blows up the memory consumption. Using a simple LOD system for mesh creation would probably cut down memory usage a lot. One idea I had was to use a larger step size when going through the arrays for chunks that are off in the distance or to collapse the voxels using a sum (or something similar) operation when creating the mesh.
I think the octree would be of greater use in terms of creating meshes (and cutting down on memory) rather than saving on voxel counts (but it would do both so it's definitely something to think about). Chunks can be dumped to a file and retrieved fairly quickly so there's no real reason to keep them in memory if they aren't in the vicinity of the player.
These are a repost of earlier work. Don't move until the terrain is done it's initial generation, hit E to pop up above the terrain. Once it's done, wander around all you like, there are only ever 32x32 chunks in RAM (unfortunately I never got around to fixing digging so it's still disabled). The meshes are what chew up ram in this implementation. The voxels only soak up 8 or 64 megs of ram respectively.
EDIT: You can safely look around and hit e during the initial generation. You'll know when it's done because no more terrain will pop in until you start moving around (at which point you don't have to wait when you see the terrain pop).
jc_lvngstn do you have the latest source posted online? I'd like to play with it, love the terrain look that you achived
btw can unity3d be used with c++ code, if so perhaps this noise lib would be perfect for this project:
example of what it can do:
At first, I was surprised when you mentioned that the meshes were taking up so much memory...until I realized...if the blocks themselves take up 64 megs for your world...the meshes are holding a lot more information probably. Just imagining how much vector data is in there...yeah
Also...there is a memory leak or something, somewhere. Let's say I run and use 725mb...when I stop, task manager still shows Unity using 400 megs or so.
Joining triangles in the mesh may work for terrain that is the same type...like blocks and such.
Mesh.Optimize() doesn't appear to do anything as far as I can see.
I did a build, and ran that. My memory usage with a terrain of 16x16 chunks, each 32x32, used up a little over 400 megs.
Loading up Minecraft, it used almost 700 megs!
So...maybe this isn't something to panic over. Does it put sort of a damper on some of my plans? Absolutely...I was actually planning on having MORE meshes in my scene. But, I think there are some things I can do to mitigate this...
First...I can not draw the 24 furthest chunks (6 chunks in each corner of the map). These are so far away...I don't think anyone cares. I estimate that would save about 30 megs. If I get greedy, I could knock out the 10 chunks from each corner, rounding out my world map 'square' even more. That would give me an estimated 50 megs back.
I'll likely use fog, which makes the furthest chunks well...foggy, you can't make out any details only a horizon. I ran it, and I think I can just drop the size of my world map to 12x12 instead of 16x16...without it being very noticable at all. This would cut my memory usage down to about 180 megs.
All just estimation, of course. But a build showed my memory usage down to a little over 200 megs with a 12x12 world.
So...it's cool I think. I 'm not a little more concerned about things not clearing out memory when chunks are destroyed, but I can investigate that more.
And...I'll probably have an option to choose your world size. People with less memory can knock off a little...for big benefits. Those with more...can add more distance. Everybody wins!
I'm hoping to get another post online this weekend. My time has been a little short this week.
I JUST WANT LIKE TWO WEEKS SOLID hahahah.
And...yes, unity can use external dlls and such...but I believe you have to have Unity Pro for that...which I don't...YET. If anyone has the port to C#, that would be neat
Looks like I should finish porting libnoise to C#. I ported some of it for my terrain. I'll start on that when I get back from Unite.
I guess I'll finally have something worth putting in my signature
I'm so JEALOUS. Wish I could go to Unite
Have fun man
I'm pretty stoked. I've never been to Montreal before, been by it many times (ie: I've seen it from the highway ) so I decided to take a couple of weeks off so I could wander around a bit and visit a friend in Ottawa on the way back. I leave in a few hours, should be there Saturday. Gonna be a blast.
Edit: I'm still really curious about what's going on in classroom 1 on Friday at 10. The schedule says 'secret'
I wonder what it is...
It's a flogging session where the now enormous Unity staff get to make fun of people like me, who've been using the product since before v1.0 was released and still can't program a loop on their own (i.e., silly designer types who think they can code).
At least Eric5h won't be there. That would just be rubbing salt into the wounds.
I had been doing my own Noise functions, but when @Taintspore mentioned libnoise earlier in the thread I went looking for a .NET version. I downloaded this .NET port of libnoise, stuck it in the /Plugins folder and it seems to work just fine with Non-pro Unity so far.
comeon screenshots now!