Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Procedural Terrain with Dense Forests

Discussion in 'Works In Progress - Archive' started by jc_lvngstn, Jul 1, 2013.

  1. TerraSame1

    TerraSame1

    Joined:
    Nov 12, 2010
    Posts:
    151
    "Refined Approach...."
    Yea Right...
    LOL

    Ohhhh... By the way....
    Get this... I have thought about doing a take off of your quotes for awhile now... So, just for fun... And I quote...
    "A year from now... Hell it's been 8 years and even though I think I'm moving forward... I'm really stumbling through the fog...
    None the less, I'm using the talents I possess and along the way, it's good to go through life with a tune in your head so just in case the best singing birds in the forest are taking a day off... I still here the best music...."
    Sorry Karen and Henry...
    :)
    Ok... Now back to work.... Where was I ?
     
    Last edited: Jul 15, 2013
  2. Vanamerax

    Vanamerax

    Joined:
    Jan 12, 2012
    Posts:
    938
    lol


    On the grass on slopes topic, I think you can either set a certain thresshold in what steepness it will follow the terrain normal and when it wants to point upwards, or you can make some kind of Lerp function where the terrain normal and upwards normal gets lerped, based on the steepness (not sure how exactly this will work). Either way, you have to find some mid-way of steep slopes for the grass and flowers to point at. When the terrain is very steep and grass follows its curves, it will just look plain wrong (as you could also be able to view the grass panes from the top, destroying the illusion of grass)

    In the last screenshot you posted, I think the grass should point just a little bit more upwards, like a quarter of the angle between the up and terrain normal. Though it doesn't look that bad on this slope yet.
     
  3. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    So, I'm trying to decide how I want to proceed with this project. The main reason I did this was so that I could use it for my main project I'm working on, as a replacement for the built in terrain and vegetation system.

    But others have expressed an interest in using it. A nice, polished system with a slick UI...is just not what I set out to do and my main project doesn't really need that. My primary project IS a part time job in addition to my full time non-game related job (boo). If someone wanted to use it for their own system, they would first have to get how it works (not that big a deal), and second have to integrate it with their project. It handles distant trees very, very differently than Unity's approach.

    Here's are my options that I can see:

    1. Just vanish with it, merging it into my main project, and keep it to myself.

    2. Put what I've got out there for everyone to use freely, but I move on back to my main project.

    3. Work with someone else willing to focus on the UI part, while I focus on making it more usable for the general population and not just programmers. The goal would be for it to become a useful alternative to the built in terrain/vegetation system, with distant and detailed trees. It would have a UI for painting, adding assets/prefabs, that sort of thing. Something nice. If nothing else, maybe it would useful as a learning tool for other

    I would only be willing to do #3 if someone were dedicated to the UI part, and even then at my convenience. I really don't have time to pour into this (or much more, anyway), so I don't know that I would consider putting it on the asset store. I wouldn't be making any concrete commitment to future maintenance, for future versions of Unity.

    I think there is a place for an alternative, full-featured heightmap based terrain system. I haven't seen any unity terrain that can deal with this many trees, at such a distance. Plus, there are so many options that are available. Different grass types (single quad, double (cross) quads, triple cross quads, and more on top of detail support. Conform to slope for individual grass or flowers. It could get incredible diverse. Density restrictions based on an animation curve for slope. I think there are many, many possibilities. Heck, the heightmap class itself is something I wish I had a long time ago. It has very handy functions for heightmap height and normal(slope) interpolation. No more trying to remember if you need the coordinates in world coordinates, or convert them to a scale of 0..1. Ugh. Just use world coordinates, that's what everyone really cares about right?

    And this system likely isn't for everyone. There are some caveats to the distant trees (aren't there always?) Nothing major I think, but you may decide it's not for you.

    Anyway...I'd appreciate suggestions from the community. If there isn't much demand, I may just toss it out on dropbox and let people in general do what they want with it.
     
  4. TerraSame1

    TerraSame1

    Joined:
    Nov 12, 2010
    Posts:
    151
    JC...
    That is quite the letter... WOW...
    There is one point that might affect your decision.... If you haven;t, you must consider.... I am sure and I know there are Unity users out there very interested in your work and your concepts.... If you don't get millions of reply's... Don't fret... What you need to consider is the fact that ALL of us Unity Designers ALL or at least ALMOST ALL.... Have two lives like you.... One that revolves around game design and another the pays the bills... So, don't make a hasty decision... We all have our pet project and it is most difficult finding good knowledgeable people willing to dive head first into another project.... Your research and development and your thread here is being followed by more than you know... In that last post where I added a link to my "About" page pertaining to the two fog systems, drove 15 people from 9 countries to look at my "About' page 27 times In JUST a half a day... And more the next day... I am very interested in your work. Even more since our Skype call where you showed me your magnificent terrain mesh LOD system... Now that, I would love to get my hands on..... It looks like I need to try Lar's Vegetation Shader too. And I love your Tree/Grass system..... Totally awesome... There is most definitely others who would love to see your systems the way you showed me.... I would help you as you wrote but I'm so busy with my pet project and to tell you the truth, I'm plan ole lousy at code writing... So, I'm not the person you wrote about finding.... One thing for sure... Don't let your work fade away.... Thanks for sharing your concepts so openly... It's been great keeping up with your thread... :)
     
  5. virror

    virror

    Joined:
    Feb 3, 2012
    Posts:
    2,963
    Looks very interesting indeed!
    Did you use the same approach for the trees that we talked about in the scripting thread?
    ANy automatic billboarding/LODing?

    Might be interested to help you out working on a GUI.
     
  6. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    Thanks guys :)

    I'm not using any billboarding or LODing. What I've shown here is -just- for distant trees, nearby trees I'd just draw the meshes and use LODs or something. It's two crossed planes intersecting for each tree. Tall grass, basically. I know, crazy heh. But personally, I'm hopeful that it will be a good solution for my particular project. I don't have to rotate them to face the camera. I don't have to worry about the tilting effect. All tree billboard textures are combined into one atlas. And this is for -distant- trees, not trees right up in your grill.

    It works off a 2d array of data right now, but could make it work off of splat maps instead. Here's how it might work:

    r - tree type. Gives you 255 different types of trees you can have.
    g - tree position, at that pixel. 0-255 means you have a virtual grid of 16x16 points within that location to place the tree. This allows you to place trees to the nearest 0.0625 meters. The calculation is pretty easy, and my intent is to make this transparent to the developer. You just give it world coordinates, and it places it as close as your resolution will allow. Using a larger tree splatmap (treemap sounds nice) than your heightmap will give you greater detail.
    b - rotation. 0-255 multiplied roughly by 1.4 translates it to 0...360 degrees, in increments of 1.4 degrees. I feel this is plenty for distant trees. But again...it is transparent to the user.
    a - height. 0-255. The developer could specify a resolution, so that instead of a 1:1 value (255=255 meters tall, which would be overkill) instead you could set the resolution to 0.5. This means that 255=128 meters, and basically let you control height to the half meter.

    I don't set colors on the trees. Their normals are set to the same normal as the terrain, so they match the terrain shading. I actually like the look.

    But really...this is something that people can customize for their own needs. You can totally ditch the splat approach and just have a data structure in memory, and go crazy on height, coloring, etc.
    You might use a perlin noise function to determine heights instead, and use the extra splat byte for more position resolution. Two bytes to store position per pixel, a total of 65536 positions. That's a 256x256 virtual grid within EACH pixel where you can place trees. Basically, placing trees to the nearest .00390625 meters. That's pretty good accuracy.
    And trees are not drawn individually, a patch of them is generated and the mesh is drawn after that, hence the (relatively) few draw calls and speedy performance. Culling is preformed per patch, instead of per tree.

    Downsides:
    You can't have more than one tree per treemap pixel.

    If you use a LOT of tree varieties, your atlas can only hold so much. Detail will probably suffer...but again, these are -distant- trees.

    If you look down at a steep angle and the trees are close enough, you can see that they are two planes. At that point, you would have to increase the draw distance of your detailed trees.

    You can't really use trees that are not bilaterally symmetrical. Like...leaning trees. This would look odd as two intersecting polygons, the tree would be definitely not match the transition to detailed trees.

    May not be acceptable for some trees like palms, with very distinct leaves.

    I keep thinking you could pass in a mesh full of polygons, and STILL orient the individual polygons to face the camera, and achieve a billboard effect. I don't see why you couldn't pass in the vertex offset from the pivot using the vertex colors. Rotate them to the correct orientation around the Y axis to face the camera. It wouldn't work for ALL possible situations, but it might work for many. Wish I knew more about shaders.
     
    Last edited: Jul 17, 2013
  7. notice_enclosed

    notice_enclosed

    Joined:
    Jul 21, 2013
    Posts:
    2
    hi jc_lvngstn. i'm playing around with an own terrain generator, with an own terrain mesh etc. could you show me your base solution to me? it could or would be helpful. just like your code style. please delete all secret algorithms and special functions for grass and trees, in case you like to do more with it. actually, i'm only interested in that base terrain mesh generator, for comparison only :) really no problem if not
     
    Last edited: Jul 21, 2013
  8. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    Sounds like...a trade? :)

    Funny you mention the terrain generator. I didn't like the approach I had before...where I regenerated the entire terrain when you moved a certain distance.
    So, now each LOD area you define moves itself, and only generates the patches that need to be regenerated. A nice performance boost. There are a few glitches left, but shouldn't take long to take care of that.
    I have another script that generates its heightmap data from an existing terrain created in Unity. My idea is, use Unity's terrain to get started, paint trees, grass, etc. Then "convert" it to my format.

    Anyway...I need another few days...maybe a week to finish my cleanup/fixes.
    My goal is to release it to the community, and let people mock er improve upon it ;)
     
  9. notice_enclosed

    notice_enclosed

    Joined:
    Jul 21, 2013
    Posts:
    2
    hm. just surprised how many draw calls a simple terrain scene of 200k vertices costs in unity. so i thought, and please correct if i'm wrong, it could be easier to create an own terrain mesh, also for special optimization like with voxel based landscapes (mesh simplification etc.).

    that would be very, very nice

    a trade? uh :) like... a dinosaur? ok. i'll show by the time what i am up to. it's much about unity terrain performance on ios/android
     
  10. janpec

    janpec

    Joined:
    Jul 16, 2010
    Posts:
    3,520
    I would be very interested in it, nice work you have there. Rendering trees at huge distance is super thing, hope performance is ok. Also are you using Lars ultimate shader for surfare?
     
  11. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    I think the terrain in Unity gets a lot of drawcalls because it breaks things down into more "patches" than I do. But my system's LOD works differently also.
    Anyway, with my terrain you can decide the resolution of the terrain, and also how many patches it is broken into. This lets you fine tune different areas for performance. For example, if you could break an entire terrain into 4 patches...you will obviously get MUCH lower draw calls (4 at the most). But you will also be pushing a LOT more vertices, since you are drawing the entire terrain.
    If you break it into smaller patches, you get more draw calls, but you are drawing less because of culling.

    The biggest thing that bothers me about the terrain is the LOD complexity. Managing it while the player moves, shifting patches, managing LOD borders and stitching them...it's been a challenge. It works, but I can't help but feel there must be a simpler approach, I just don't know what it is.

    Sorry, when I said trade, I don't want you to give up anything secret. But after looking at the terrain system, if you have any ideas or input on how to improve it, that would be very useful.


    I'm pretty pleased with performance. I'm running an i7 920, a low end quad, with a GeForce 560. In my screenshots in the post I usually show the Unity stats in the top right, and my actual fps in the top left. Memory/vertex count is what you have to keep an eye on. I filled my entire terrain with trees...4 million or so, minus the land area covered by water. I want to say I got around 50fps...but that is so many trees, you are looking at 2+ gigs of ram just to draw the environment. I guess I need to try duplicating it in Unity's system and see how well it performs, to get a real comparison.

    But there are a lot of things you can tweak...grass density, grass polygons (single, double cross, triple cross, etc). Terrain resolution. Tree distance.

    I need to check where that shader came from...I pulled some stuff from the wiki, and I'm also using the Relief Terrain Pack. When I release it, I have to make sure I am using an open source terrain mesh shader instead of one of theirs heh.


    I do want to make sure it's clear that the distant tree system is not done the way Unity handled it before. Trees are basically tall grass, handled by a splat. This means one tree per splat pixel, you can't drop down 5 trees at the same location. Also, their are two intersecting planes, so if you want to use it for a flight sim, you'll either have to use different geometry, or it will look goofy when you look down. Also, you still have to draw detailed trees nearby, and I haven't gotten to that part yet but there will have to be a built in "switch" that transitions from distant tree to detailed tree.

    I'll try to post some more benchmarks in the next day or so! My terrain is 2048x2048, sized to 8192x8192 (6553 meters high). If anyone wants to script a tree every 4 meters and do some benchmarks with Unity's built in system, we can compare.
     
  12. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    I asked for some assistance with a billboard shader, that can handle individual polygons even though they are part of a mesh. In this thread:

    http://forum.unity3d.com/threads/192652-Billboard-shader-using-vertex-offsets-in-color-or-uv2-data

    Neyl posted a shader that did exactly that. It has lower memory usage for the trees, almost half.

    Unfortunately, we need to improve shader quality by bringing back soft edges and having the lighting of the trees affected by the vertex normals. I'm trying to get assistance for this, or find out how on my own.
     
    Last edited: Jul 30, 2013
  13. duclaw

    duclaw

    Joined:
    May 9, 2013
    Posts:
    44
    the terrain is beautiful and realistic, did you make the grass yourself?
     
  14. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    No, the main grass shown there is the texture that comes with Unity. I would love some better free grass textures to include in the package thought!
     
  15. TerraSame1

    TerraSame1

    Joined:
    Nov 12, 2010
    Posts:
    151
    Hey JC... I have wondered about your Terrain Mesh LOD system... I think you have that devised for a single terrain mesh... So here is the question... Do you think it might be possible to make that work where the system can work with a multiple terrain mesh system and the edges take into account the neighboring terrain meshes?
     
  16. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    That's an interesting challenge...you mean just stitch the seams for the mesh, or also take the terrain into account? Would there be a problem with just dynamically extending the main terrain mesh to include the new terrains, and be able to remove them also? I think that would be my preferred approach, rather than somehow making them "smart" enough to be truly separate but seamless.
     
  17. TerraSame1

    TerraSame1

    Joined:
    Nov 12, 2010
    Posts:
    151
    Hey JC....
    Thanks for the response....
    About the Multiple Terrain Mesh situation... I have a 12 x 12 mesh matrix where I have a 2048 x2048 texture on all the middle meshes and lower res textures as you move away from the main playing area... This allows me to use satellite imagery.... It is the only way to create full simulations of real places, similar to Google earth... So, a multiple mesh terrain system is imperative.... The Mesh system is my main concern as a good system could possibly make my sort of project work on mobile platforms and really would rock the world.... I realize I would still need to lower resolutions and other things but an LOD system for my terrains would really help frame rate... Without trees and LODs of buildings etc I get a frame rate of near 400 fps... When I add trees it drops significantly.... None the less.... a good terrain mesh set up would help run even bigger projects.....
    So, thanks and good day...
     
  18. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    The way it works now, imagine your player at the center of a rectangle. that would be your highest detail region.
    That rectangle is at the center of a larger rectangle. That is a lower detail region. And so on. The outermost rectangle is the lowest detail region.

    For each region or rectangle, you can assign a material. So the innermost, most detailed area around the player would use a high detail shader...many textures, bump mapping, etc.

    Also, each rectangle/lod region is split into patches. This is so that culling can cut out patches, and also to avoid the 65k vertex limit. Each patch is a mesh, which draws from its part of the main terrain material. All patches of a region share the same, main terrain splat texture and draw from their portion of that texture.

    But, the system could be changed to work for you, probably without much hassle. You would just assign a separate material or texture PER PATCH (instead of per region), and each patch would draw an entire texture instead of just a portion of the entire map texture. Hope that makes sense.

    So, if you have three lod regions around the player, and each one is split into 4 patches (2 across, 2 down), you would need 12 patches total to display the entire map. That would be 12 materials, each one with its own individual texture.
    The materials wouldn't be using splat/multipass shaders at that point, just diffuse or diffuse/bump :)
     
  19. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,834
    A couple of ideas. .. when you have really dense foliage or forest, most of what's in the mid-ground and distance covers up all of the `rock surface`, so really doesn't need to be rendered.. if you could predict where the coverage was so dense that it obscures all sign of the surface underneath then you could cut out a lot of triangles and speed things up, or even make your coverage even denser by giving more triangles to trees etc and less to land you can't see.. When you look at a grassy field you don't usually see much in the way of earth.. you see lots of grass. I presume you have a triangle limit per mesh and generate lots of meshes so could just switch off mesh chunks temporarily if they are far enough away and fully covered in plants/trees.

    Another idea I had, is that all of your landscapes are basically heigh-map based. Without straying too far from the heightmap concept you could for example give some extra vertex data to the meshes and then use a modified vertex shader to horizontally displace vertices. You could encode it in vertex colors or an extra uv channel or something you're not currently using. Like in your heightmap, if you use the Red/green channels to encode a 16-bit height, you could use Blue and Alpha to encode X and Z displacement. Then you can just add those values to the vertex coordinates. It would let you create some overhangs and stuff that jutts out over the land below, providing you with some more interesting shapes. You could still procedurally generate it all. Also for example if you have two steep hills next to each other you could in fact form a bridge between them with a hole underneath, by extending out the triangles from each hill until they meet/overlap, using horizontal displacement. Obviously it's still heightmap based so as you go further up the hill slope you'll be stretching out the vertices of vertexes that are `further away` from the other hill, but you could also additionally displace higher-up vertices horizontally so that they in fact form a vertical wall, or even a wall that overhangs and turns into a bridge. And with some careful adjustment of this you could actually have several bridges above each other.
     
    Last edited: Jul 31, 2013
  20. Vanamerax

    Vanamerax

    Joined:
    Jan 12, 2012
    Posts:
    938
    Also, extending on imiginaryhuman's post, with very dense fiolage, you can try to replace the transparancy shader with a standard diffuse one (which is cheaper to render) As it was so dense to cover up the ground anyway, it doesn't really matter. Just be sure that the rest of the now non-transparent part of the texture isn't noticable, so you would have to go with some color like green or a gradient. I haven't tested this so I'm not sure how well this works out.
     
  21. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    Very interesting ideas! Thank you both for the input.

    Culling terrain under very dense trees...well, it would certainly help fill rate. I was planning on using the simplest terrain shader possible for distant land, but every little bit helps. I just don't know what the algorithm would look like, and it would look bad if there were any open spots. But yeah...there are a lot of places where all you see is trees.

    It might be useful to skip trees, based on distance. Maybe at the most extreme distance, it only draws every other one. It would require the shader to be able to skip them, and also somehow track which one to skip and which one to draw.

    I like the idea of using color channels for vertex displacement. I'd have to tweak the height and normal interpolation functions, but that might not be that big a deal...heck it might actually be very straightfoward. That might be pretty interesting...I would probably have it as a separate type of terrain script, people could use the "simpler" one or the more advanced one with the modified vertex shader.

    I wish we could use other data types instead of just Vector3 for vertices. Most of my mesh patches could easily be drawn with a Vector3 using short values, instead of floats. I would just have to introduce a single float for the mesh, to scale the vertices by. That would save a decent amount of memory...6 bytes per vertex, instead of 12/ OpenGL seems to support other vertex data types, maybe sometime they'll open them up to unity.

    I guess I need to go ahead and get this to the community, I've been drawn onto yet other side projects but this is starting to become too many screenshots and theory and not enough stuff for people to get their hands on.
    Tonight, I may go ahead and put what I have out there. It works (there are a couple of glitches with terrain but nothing major), it just doesn't have a nice UI and there is some code cleanup I could do. It's like...beta open source code or something. I'd like for it to be all lovely and polished, but oh well. It's free.
     
  22. Vanamerax

    Vanamerax

    Joined:
    Jan 12, 2012
    Posts:
    938

    Sorry if I'm wrong at this one, but you can just use half3 or fixed3 positions for very distant trees in shaders right? I bet you won't really notice the imprecisions at such a distance and they are much cheaper for the shader to play with (not sure with converting to different types though). Combining all ideas from the previous few posts, I think the best solution is to make several shader versions. So one for the, well.. closest distance trees (highest precision values, alpha, small patches and more triangles), one for the most distant trees (no alpha, low precision etc.) and maybe one for inbetween which has several tradeoffs and improves the LOD switching basicly. It all comes pretty much down to balance and compromising
     
  23. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,834
    You can use smaller datatypes in the shader yes but the vertex data (the mesh) itself will still store colors etc as floats.

    Also you could try just having level-of-detail where if a mesh chunk is a) fairly distance, b) covered in foliage, then use a much reduced low-poly version just to capture any stray bits of land that show.
     
  24. jc_lvngstn

    jc_lvngstn

    Joined:
    Jul 19, 2006
    Posts:
    1,508
    Ok, so I will be out of town next week, and I am bogged down in a separate part of my project also. Some have asked about the terrain and its availability, so here it is:

    https://dl.dropboxusercontent.com/u/174731243/AMTerrain%20v0.0713/AMTerrain%20v0.0713.unitypackage

    I sincerely hope it is of some use to someone! It's not polished, heck the tree stuff still has references to "Grass". Anyway, the active terrain in the Hierarchy has the four primary scripts attached: The heightmap script, the AMTerrain script, Terrain Grass and Billboard Trees script (bad name I know).

    So...Grass Density in the Terrain Grass inspector controls grass density. Same thing for Tree Density in the tree script.
    I'm not happy with how detail mesh normals are working...they are too dark. Not sure why this is at the moment.

    [Edit] A checkbox in the tree inspector now switches between billboard and bisecting tree types.

    So, sorry it's not a nice, polished terrain editor and all, fully commented code, etc. It was either wait until I return to the terrain system (not just real soon), or go ahead and give what I have.

    Ideally, I think I would make it so that you can import a terrain to a unity terrain, paint it with textures, trees, grass and all...and then have the AMTerrain system use that information instead.

    I tried to make sure there was nothing from any other commercial packages in this package. It uses free shaders from the wiki and the one generously granted for the billboard tree.

    My -only- request is that someone will actually offer suggestions on how to improve performance, logic...heck anything. If you find this useful, please *please* give something back for everyone else to benefit from also. I'd love to make it a better system for everyone, even if I don't personally deliver a "finished" product for general use.

    I am more than happy to answer any questions about the system. Again, I'll be more or less away next week so don't expect an immediate response.

    Almost forgot:
    In AMTerrain.cs,

    Code (csharp):
    1.         _WorldData.CreateLODRegion(2048, 8, 256, _DistantTerrainPrefab, _HeightMap);
    2.         _WorldData.CreateLODRegion(512, 4, 128, _NearTerrainPrefab, _HeightMap);
    3.         _WorldData.CreateLODRegion(256, 1, 64, _NearTerrainPrefab, _HeightMap);
    This where you define the LOD regions. The first parameter is the size, the second is the resolution (so 8 = 1/8th, 4 = 1/4th, etc). The third parameter is the size of patches that each lod region is broken into. So the larger the patch, the less meshes required to draw the terrain.

    So do like this example: Let your first region be the largest, with the highest number for the resolution, and a high number for the patch size. As you add LODs, they are smaller and more detailed around the player.
    So the 2nd number is sort of counterintuitive...the higher the number, the more pixels it skips to draw the terrain. Think of it as, the higher the value, the coarser the terrain.

    With the third number, the higher the value the more patches the lod region is split into.
     
    Last edited: Aug 10, 2013
  25. AdamGoodrich

    AdamGoodrich

    Joined:
    Feb 12, 2013
    Posts:
    3,780
  26. DryTear

    DryTear

    Joined:
    Nov 30, 2012
    Posts:
    312
    Taking voxel, to a whole new level.

    Hopelly this terrain could be edited.
     
  27. GenericGame

    GenericGame

    Joined:
    Nov 26, 2012
    Posts:
    206

    JC< you are crazy guy! You started the insane After Playing Minecraft Thread and now you are starting the next epic thread about real terrain generation. Let me finish my first block game, geez!
     
  28. dirtybassett

    dirtybassett

    Joined:
    Oct 3, 2012
    Posts:
    59