Content: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Background: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Pattern: Blank Waves Notes Sharp Wood Rockface Leather Honey Vertical Triangles
Welcome to TerraFirmaCraft Forums

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    • Dries007

      ATTENTION Forum Database Breach   03/04/2019

      There has been a breach of our database. Please make sure you change your password (use a password manager, like Lastpass).
      If you used this password anywhere else, change that too! The passwords themselves are stored hashed, but may old accounts still had old, insecure (by today's standards) hashes from back when they where created. This means they can be "cracked" more easily. Other leaked information includes: email, IP, account name.
      I'm trying my best to find out more and keep everyone up to date. Discord (http://invite.gg/TerraFirmaCraft) is the best option for up to date news and questions. I'm sorry for this, but the damage has been done. All I can do is try to make sure it doesn't happen again.
    • Claycorp

      This forum is now READ ONLY!   01/20/2020

      As of this post and forever into the future this forum has been put into READ ONLY MODE. There will be no new posts! A replacement is coming SoonTM . If you wish to stay up-to-date on whats going on or post your content. Please use the Discord or Sub-Reddit until the new forums are running.

      Any questions or comments can be directed to Claycorp on either platform.
dreadicon

Plate Tectonics WorldGen (co-programmer needed!)

33 posts in this topic

So, I've been working on a project for some time now for use with TFC. The problem is it's a rather....large project.
 
I am building a plate tectonics map generator.
 
Why? Because it produces realistic, interesting, dynamic, logical results. 
 
-Use real-world geology to find rock types
-Explore massive plains, coastal mountain ranges, volcanic island chains....etc.
-Biomes which are dependent on geology to create deserts, forests, jungles, etc.
-Rivers which flow downhill, meadows in forests, mountain lakes, etc.
 
And what does this require of Bioxx/Dunk? Nothing! (per-se).
 
Because tectonics pre-render the world, this can be done entirely independent of the game, in a program written in any language. It COULD be written in Java. Or C++. Or C#. Or Javascript.
 
Now, obviously TFC could add aspects like meadow grass, meadow biomes, and so forth, but it's not inherently necessary; this could just plug straight into the map format!
 
Back to why I am making this post: Plate tectonics aren't easy, simple, or efficient. They present many coding challenges. Working with one colleague we put together a proof of concept program which implements a C++ plate tectonics library, exporting the result to a minecraft map. It's only vanilla stone & water, but the results were very promising. mountain ranges, island chains, prairies, and rational continents were formed, and stretched as far as the eye could see. unfortunately, my colleague is unable to work with me on the project any more (though he's still available for the occasional question concerning it). While I will finish it eventually, it would do wonders for my motivation and productivity to have someone to work with. 
 
I was just starting to port the project to C#, but if a C++ guru were to pop up, I have no qualms about keeping it in C++.
 
So, if you are a programmer, or know someone who is and would be interested, please let me know! I have a design document and an old github repo for the last iteration before I began my rework. Can provide any details requested!
 
Some heightmaps generated with the proof of concept are attached; I will attach some in-game minecraft pictures later.
(credit goes to http://sourceforge.net/projects/platec/ for the original proof of concept and images, though I was building an entirely new codebase to accommodate things like rock layers. I have also run unit tests after building his code myself. It runs surprisingly fast (2 minutes for 512x512)
 
here is a link to the Design document:
You may feel free to comment; please leave your name or handle if you do so!
 
 
(likely) FAQ:
 
Q:"If you make the map in a seprate program, is the world still as big?"
A: In short, no. The world has to be pre-generated, therefore it must be very finite compared to minecraft's procedural generation. However, the maps generated with this program would take 24 hours to walk from one side to the other. Before starting on this concept, I asked many players who spend most of their time exploring, and found that few wander beyond a certain distance. The map will be double that distance in all directions, and have a sheer cliff with empty blocks all around ('end of the world' style). Perfect? No, but IMHO trading a 1% edge case for an improvement to the game overall is worth it.
 
Q:"Will it really be that much better? Tectonics seem excessive."
A: Well, that depends. Personally, I see the fractal patterns, the artificial boundaries and shapes every time I play minecraft. It just doesn't feel right. But even that aside, there are some thing in nature that fractals just can't simulate, or are very difficult to simulate. The feature list I placed above is a few such things.
 
Q:"Is this really possible?"
A: yes. it will take a lot of work, no doubt, but it's definitely possible. I've run unit tests and theoretical numbers; everything says this is possible. Heck, I've already got one that creates a real minecraft map.
 
Video demo of PlaTec in action (the program used for the Proof of Concept build, see pretty animations!):
 
Some stats for PlaTec in smaller scales which were run by the creator of PlaTec and verified by me on a similar machine (Core 2 duo 2.5 Ghz, 4GB RAM Laptop I have lying around). Columns show the size of the heightmap, and rows show the number of plates used. The code is also not as optimized as it could be. Source: http://www.theseus.fi/bitstream/handle/10024/40422/Viitanen_Lauri_2012_03_30.pdf?sequence=1

post-3277-0-02004200-1401409293_thumb.pn

post-3277-0-15826800-1401409294_thumb.pn

post-3277-0-85526800-1401409294_thumb.pn

post-3277-0-33567900-1401409295_thumb.pn

post-3277-0-94907100-1401594935_thumb.jp

8

Share this post


Link to post
Share on other sites

Doing something like this has been kicking around in the back of my head forever (since before Minecraft, just for generating realistic maps in general), but it's never gotten beyond the design stage. My C++ is a bit rusty, but it was solid back when I used it regularly, so I'm sure it will come back. I've never used C#.

 

So, I'm interested in helping =^).

0

Share this post


Link to post
Share on other sites

Well, I'm in no position to help, but I'm interested in the mod when you've finished.  I've worked a bit with World Machine to make TFC maps via World Painter imports, so I can attest first hand that realistic world generation really does amazing things aesthetically for the game.  That method of course is extremely tedious and can't do things like rivers very well.  Beautiful erosion though.

 

I hope you get all the help you need.

 

Looking forward to what you come up with.

0

Share this post


Link to post
Share on other sites

Ah! Thankyou both for your support!

 

@TowerOfGlass - Sounds great! I'll be sending you a PM shortly so we can discuss things like methods of communication. I too have actually loved the idea of plate tectonic/realistic world generation since long before minecraft! It wasn't till TFC that I really felt driven to make it a reality (also, wasn't till the last couple years that I had sufficient coding experience to think about it either xD). I look forward to talking more in the near future!

 

@Tsuarok - Thanks, encouragement always helps! I can keep you updated as the project matures if you are interested in helping test things out. Interesting that you mention World Machine; I think the erosion procedures in that program are among the best there is. Thanks for reminding me of that! I wish I knew some of their equations, or maybe some way to pipe the output into World Machine and have it apply a few universal filters or such.

 

If anyone has any questions or comments just let me know!

0

Share this post


Link to post
Share on other sites

I'm in a similar position as TowerOfGlass as I've been interested in a very similar project as well. The goals I was personally aiming for were the following:- Basically a "world manager" daemon that runs alongside the Minecraft server and handles the heavy lifting behind world gen and chunk updates separately.- Designed to scale and take advantage of parallel and distributed systems via MPI. It should be able to utilize clusters.- Ideally a modular hot-pluggable architecture that would allow for new environment features to be added and removed without having to regenerate the world or even restart the server for that matter.- Not just geological systems, but support for a dynamic biosphere as well.- GPGPU support???- Written in some combo of C or C++ with possibilities for Python and/or Haskell on the high-level stuff.- Would target Linux and server environments primarily.- Free and Open source.As you said yourself, this all a ton of work much of which lays far out in the future, but one needs to start somewhere. If you'd like another hand, I'm familiar with C/C++ (not C#) too. I don't know what direction you're aiming on taking this ultimately beyond the description you've already given, but the rough list of goals I've given above should hopefully represent where my priorities are. If you see an overlap of interests, I would LOVE to help! And even if you don't, I'd be happy to contribute code anyways. :)tl;dr - I'm a programmer.

0

Share this post


Link to post
Share on other sites

I'm C#/C++ programmer and I'm definitely interested. The problem I have is that you are removing one thing that is integral to minecraft game: infinite map and it's generation. Also, 512x512 is far from acceptable for minecraft map. You are saying that size of the map will depend on how far people generally go. For me, I usually go as far as 1 MC day(light) in one direction from my home. In this day, I can go 1000-1500 blocks. That is 2000-3000 blocks in one direction. 4000-6000 is double that. If we say make a map 4096x4096, then that is 64x bigger than the one you tested. Assuming linear complexity that would take 2 hours to generate. And that is only for the simple algorithm without the rock layers and all the nice things.

If you really want to pre-generate somehow realistic map, then I'm sure there are faster ways that give some kind of believable results. Something like combination of voronoi diagrams with some noise would be much faster.

 

And plate tectonics is one thing. But I think erosion is just as important. Many natural features and especially rivers are created by erosion. Also, sedimentation is important to create many rock types and sand. This would again increase complexity and time needed to generate the map.

0

Share this post


Link to post
Share on other sites

So after thinking about this. I got this : As long as you don't need real-world geology, then this should be possible.

 

Heres how:

  • Generate heightmap using plate tectonics on small map(512x512)
  • Scale up 8-64 times
  • Add some height noise to make the scaling less noticable
  • Change to 3D map with randomly chosen rocks in layers (maybe using some data from tectonics run)
  • Run water erosion. This creates rivers and lakes. Erosion erodes the rock and deposits sand (and/or gravel). Some rock types are easier to erode than others.
  • In areas that don't have high temperature and low humidity, change the sand and gravel to dirt. Don't change gravel when underwater. Don't change sand when next to sea/in river's delta. Again, add some noise, to make it less uniform.
  • Generate ores and minerals using similar algorithm as TFC itself.
  • Generate grass, trees, bushes depending on temperature and humidity maps

This is high-level design and many details need to be figured out. For example how to create clay.

0

Share this post


Link to post
Share on other sites
@oldmanmike - I definitely see some overlap, though we have slightly different solutions to the same problem. 
From the design document:
"Simplified, quantifiable objectives, in order of importance are:

-As-good-as-vanilla micro-terrain(looking at scales of up to ~40x40 blocks) with caves

-Realistic ore and mineral generation via geology

-Rainfall/temperature based on geography

-Modular coding(core), so it is maintainable and extendable

-Minimum hardware requirements of dual-core CPU & 4GB RAM, recommended specs of quad-core CPU & 16GB RAM.

-Avg. gen time (using recommended specs) for a 32,000x32,000 world of ~5 hours

-Linux & windows compatibility

-Realistic rainfall/temperature/climate based on geography, meteorology, and flora

-Better-than-TFC micro-terrain using erosion

-Better-than-TFC biomes/trees/plants and soils based on climates, geology, etc. in large regions.

-Better-than-TFC caves based on rock type & geology.

-Avg. gen time for a 64,000x64,000 world of ~2 hours

-Misc unique features resulting from unique erosion (flood-based, glacier-based, wind erosion, etc. resulting in features like the grand canyon, Yosemite valley, sand dunes & rock arches, etc.)"

 
That said, I am not completely set in this list. I've actually decided to at least temporarily open up the design document for public viewing via a link (it's on google drive). I am also allowing comments for now, we will see how that goes. The link is here & added to the original post:  https://docs.google.com/document/d/1ZKugZXUvFdJRVa5lZAMPg7Z9OK2vr87MtSgHFXtEsVQ/edit?usp=sharing
If you comment, it would be preferable if you were to leave a signature of your name or forum handle.
 
 
@Euphoric - OK, so I perhaps did not cover these specific points of execution as well as i could have. I honestly wasn't expecting as many programmers to pop up as have! (Not that this is at all a bad thing! Just pleasantly surprised.) 
 
iirc, the furthest an explorer in TFC & Minecraft has roamed from my poll of about 30 explorers (players who specifically love to roam and explore) was +/- 90,000, with only 2 above 30,000. 30,000 blocks takes a full two irl hours of walking completely unhindered in a straight line. In practice, even with horses, it will take at least twice that time.
 
I have also run unit tests as high as 4096x4096, which does take about two hours to run. However, the intention actually never was to use the tectonic heightmaps in a 1:1 implementation. Rather, they would then be interpolated (from our initial tests 8:1 works fairly well).  At 4096x4096 with 4 pixels per square chunk (for an 64:1 block:pixel ratio), you have a world which is over 32,000x32,000. Only hardcore explorers would roam past the edge of this map. Moreover, is it really so bad if you find the end of the world? I think of it more in terms of "Have you run out of places to explore?" Note also that the unit test did not utilize multithreading or GPGPU technology, and have plenty of room for more optimizations. 
 
The exact method of interpolation is still up for discussion, but bi-linear with falloff was looking decently promising from initial research. Once interpolated, a micro-scale erosion operation would be done, either using a single advanced pass or multiple simpler passes. This is also when trees and flora would be populated precisely.
 
Funny you should mention Voroni diagrams; the proof of concept code I use implements a variant of them to generate the plates' shapes initially. But no matter what noise you use, there are some things it just can't do. Uplifted strata? mid-continental and coastal ranges? metamorphic rock placement? Granite plumes? mass-scale erosion? (tectonics important for uplift compared to erosion rates being miss-matched). I'm not completely opposed to noise and fractals, but I think that Tectonics produces results which they have not yet matched.
 
Erosion is DEFINITELY a very, very major aspect; the plate tectonics just give good data in, so that the subsequent erosion can give good data out. Erosion is what players will conciously see, so it is important. But it is also easier; there are lots of erosion algorithms and code. Comparatively there is very little for plate tectonics. 
 
 
Thankyou again to all of you voicing and offering support! I will follow-up with another post once I am off work giving more thoughts on what i have so far, and how you all can fit in!
0

Share this post


Link to post
Share on other sites

So after thinking about this. I got this : As long as you don't need real-world geology, then this should be possible.

 

Heres how:

  • Generate heightmap using plate tectonics on small map(512x512)
  • Scale up 8-64 times
  • Add some height noise to make the scaling less noticable
  • Change to 3D map with randomly chosen rocks in layers (maybe using some data from tectonics run)
  • Run water erosion. This creates rivers and lakes. Erosion erodes the rock and deposits sand (and/or gravel). Some rock types are easier to erode than others.
  • In areas that don't have high temperature and low humidity, change the sand and gravel to dirt. Don't change gravel when underwater. Don't change sand when next to sea/in river's delta. Again, add some noise, to make it less uniform.
  • Generate ores and minerals using similar algorithm as TFC itself.
  • Generate grass, trees, bushes depending on temperature and humidity maps

This is high-level design and many details need to be figured out. For example how to create clay.

ROFL, I have to laugh, because that's more or less the initial model we had used when we started. It's not entirely off the table, but it doens't seem to me like the implementation of layer tracking in the tectonic process would be more than a x2-4 performance hit, especially if done correctly. None the less, this idea definitely isn't off the table. It's worth while to at least re-visit with new eyes.

0

Share this post


Link to post
Share on other sites

I'm really not sure what to think about this. Your goals seems to be extremely high and your design document is basically "What I want it to do" without any details of how to actually achieve it. I'm especially concerned about combination of complexity of the whole simulation for both data structures and calculations, memory consumption and speed. And adding some kind of modularity into it makes things even worse. Modular code is usually hard to optimize. If you want to get some credibility, could you answer a question : What data structure are you going to save the whole world in during the whole simulation? To me, that is the most complex part, that will affect performance the most.

 

 

-Avg. gen time (using recommended specs) for a 32,000x32,000 world of ~5 hours

-Avg. gen time for a 64,000x64,000 world of ~2 hours

So which one is it? 

0

Share this post


Link to post
Share on other sites

I'm really not sure what to think about this. Your goals seems to be extremely high and your design document is basically "What I want it to do" without any details of how to actually achieve it. I'm especially concerned about combination of complexity of the whole simulation for both data structures and calculations, memory consumption and speed. And adding some kind of modularity into it makes things even worse. Modular code is usually hard to optimize. If you want to get some credibility, could you answer a question : What data structure are you going to save the whole world in during the whole simulation? To me, that is the most complex part, that will affect performance the most.

 

 

So which one is it? 

In short, yes, it's ambitious. But I have been doing my best to begin breaking it down into smaller, more manageable stages, each of which provides a tangible result. The design document is meant as a very high-level view of the code. I could outline exactly how PlaTec (the proof of concept code we found and modified) did everything, but many of the methods involved were hackish, difficult to extend/modify, or just confusing.
 
As this is an amateur project, odds are one day I will move on (I intend to see it through at least to completion & maintain it, but you never can say what life will bring). If I want the project to go on after that, it needs to take less than several weeks of painful pouring over the code and reading documentation for others to get the gist of it. The PlaTec code took me over 60 hours to glean how it works, and that much again before I could actually start thinking about changing it without breaking something. I want to build a maintainable code base so if I have to leave this for reasons beyond my control, some one else could carry on my work.
 
But to offer the best answer I have to your question directly:
PlaTec uses algebraic arrays (y * stride + x), which are (typically) very efficient. Each plate is stored separately in it's own array, which is a fairly brute-force implementation, but it works for PlaTec's purposes. There are methods which translate from global coordinates to plate coordinates, and for expanding/shrinking the array. There is a global heightmap which is created using the individual plate heightmaps, and rendered after each pass (that's where the pictures attached to the original post come from). In our implementation, we made the rendered heightmap optional, to improve performance (net improvement was small, but noticeable).
 
As to the method of data storage used for our purposes? That is still up in the air. 2D arrays, vectors, algebraic arrays, RDBs, and hashtables have all been discussed across both C++ and C#. There are functional and performance benefits and drawbacks to each. The path I have been playing with recently uses 2D arrays as placeholders for later optimization (they are easy to implement, but have poor performance), but I have not done much yet which relies on them. The tentative plan was to use 2D now, algebraic later.
 
Finally, you asked which item between the following is the target:
-Avg. gen time (using recommended specs) for a 32,000x32,000 world of ~5 hours
-Avg. gen time for a 64,000x64,000 world of ~2 hours
These are the targets at given priorities. 32000x32000 at 5 hours is higher on the priority list than 64000x64000 at 2 hours, thus the first target performance level is the #1 priority once all the criteria above it have been met, followed by the other features below it, then near the bottom the second becomes the new target priority once everything above it has been met. I apologize for any confusion; Till this point only myself and one other have been actively working with this document, so it may not be as clear yet as it could be. I will be taking time this weekend to revise wording, add description, and give more details. Moreover, until the project has picked up more momentum, everything here is open for debate in one capacity or another. I decided to post about this and open the document for public viewing/commenting in hopes of not only getting some collaborative coding, but some conceptual discussion and review as well. Changing architectural aspects is much easier now than it would be later.
 
EDIT: to specifically address your concerns about memory, the 4096x4096 resolution PlaTec simulation consumes about 3GB of ram using 64 bit unsigned integers for the points at peak usage.  When interpolating and performing operations on the 32,000x32,000x256 finalized 3D voxel data, only a portion of it needs to be loaded into memory at any given time. Once the opperations finish, the entire structure is compressed into the Anvil format, which actually has pretty good compression rates.
1

Share this post


Link to post
Share on other sites
As to the method of data storage used for our purposes? That is still up in the air. 2D arrays, vectors, algebraic arrays, RDBs, and hashtables have all been discussed across both C++ and C#. 

 

This is not what I'm talking about. PlatTec is using heightmap to store height of one stone layer. If you add multiple layers or even ability to add "holes" in the map, then you have to expect multiples of memory increase. So those 3GB quickly become 9GB with just 3 layers of stone. And this is not talking about data required to store erosion. For which you again need heightmap or two. Storing those plates is simple, storing plates with data about stone layers becomes much more complex problem.

And major problem with this much data is not what algorithm to pick, but ensuring good memory locality of data. Bad memory locality can easily result in extra slow algorithm. 

 

These are the targets at given priorities. 32000x32000 at 5 hours is higher on the priority list than 64000x64000 at 2 hours

 

This is even worse than before. You are expecting to optimize the whole algorithm 10 times? These kind of algorithms usually can be optimized few percent, but you can never get this big increase. 

 

Changing architectural aspects is much easier now than it would be later.

 

Yes. Any performance increase would require massive changes in architecture and how the data is stored.

0

Share this post


Link to post
Share on other sites

Euphoric, don't discourage him.  I really want to see what he comes up with.  Instead of talking about how wrong the ideas are, try offering constructive alternatives.

 

That said, I do know that performance will be an issue.  I will happily wait.  My 64k World Machine map took almost a week to finish rendering, though admittedly, my computer sort of sucks.

0

Share this post


Link to post
Share on other sites

@Euphoic - OK, point taken about the optimization consideration. One such scenario which can (in a few circumstances) achieve 10-20x better performance is utilization of GPGPU + multithreading, but that is a major overhaul and typically only gives about a 1.5-2.0x increase. I've set the 32000x32000 @ 5 hours as the only target number, and even that is still up for debate. 

As to data size, the raw memory usage is theoretically only about 250MB for a 4096x4096 map of 64 bit integers. I think there is some memory leakage and/or other bloat that could be worked around/fixed/optimized to bring it more in-line with the space it would actually use. I have also been toying with methods of getting better performance and rock layering. One idea was to use courser grained simulations (such as 512x512 or 1024x1024) for the plate tectonics, and increase the up-scaling at the end. You proposed such a method, and I have been toying with the idea for some time. I would still want to track the individual layers, however. Additionally, simplified data could be kept concerning things like cumulative erosion from wind/water, and other such markers for use in a new additional phase where a more advanced interpolation takes place (applying interpolation followed & intelligent noise weighted by said metadata). Once this phase is complete, it would then be polished as normal. Ultimately, more tests will have to be done before exact expectations can be set performance-wise. 

 

@Tsuarok - Thanks for the support! Euphoric may be rather discouraging, but he raises some valid points. In the end, if the full render takes over a day, I would still call this project at least a partial success. And that actually raises an interesting idea: the reason for the target of <5 hour rendering time was because inevitably you will get maps which have a boring or bad layout. It just happens when you use randomized generation; real life can often have boring landscapes too. But here's an idea: what if the program was to have a 'stripped down' version which only runs the macro-scale, and only tracks macro-scale impacting aspects, then gives the user an image and the seed used to create the world.  This should run almost as fast as the current PlaTec implementation, and let you know (very generally) how the world will look. Once you have one you like, just run the program again with the seed, and this time it will render the whole thing taking much longer. This would help solve the issues with long render times more generally speaking. Thoughts?

 

Final note: I re-ran some tests. Most of my quoted stats were from memory (4096x4096 stats excepting). Some stats for smaller scales which were run by the creator of PlaTec and verified by me on a similar machine (Core 2 duo 2.5 Ghz, 4GB RAM Laptop I have lying around). Columns show the size of the heightmap, and rows show the number of plates used.

 

post-3277-0-76786300-1401594573_thumb.jp

0

Share this post


Link to post
Share on other sites

Well. Being able to set resolution, precision and quality of simulation would allow for tuning of time required. 

 

But I still don't see how are you going to handle complexity of storing multiple stone layers and especially their formation. First, you have Igneous Extrusive, which is already what the tectonic algorithm is creating. You could add volcanoes for added detail. Then you have Igneous Intrusive, which forms from cooling magma underground. Are you going to keep information of those pockets between turns or are you just going to create random pockets of Igneous Intrusive stone? Then, there is Sedimentary stone. There are many ways this sedimentary stone happens. Both from sea creatures or from erosion. And different stones erode into different sediments. You have to track those. Also, sediments are first created as sand or stone, only after metamorphosis they become a stone. And lastly there is Metamorphic stone, which happens thanks to heat around magma pockets and from pressure when deep under ground. You need to be able to track that.

 

And difference in many rocks just depends on what chemicals are in the rock or what components get sedimented. How are you going to track that? For example, Conglomerate is described as bunch of rocks stuck together. How do you say your algorithm will create this stone?

 

The amount of data and interactions you have to keep track of to realistically simulate geology is huge. Even on small resolution map.

0

Share this post


Link to post
Share on other sites

Awesome, your generated maps look really good :-)

 

Better map generation is always great. But you can also make procedural map generators that look very realistic: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/

 

Interestingy, the other day I stumbled upon of of the TFC developers github profile and he has forked the repository for above map generator - so perhaps there's other guys working on a better map generator you could join forces with.

0

Share this post


Link to post
Share on other sites

Something to consider:  From my experience making maps, I noticed that with truly realistic terrrain, viewing distance becomes a problem.  There's very little benefit of having majestic mountains if you can only see them when you're standing on their peaks.  They loose their majesty from up there, especially since you cannot see the plains (or whatever) below.  

 

Thus, when I was making maps, I found that making things at quarter scale or lower really improved the look and feel of the map.

0

Share this post


Link to post
Share on other sites

This sounds really cool.  I would like to push for the idea of the world size being configurable.  A 2,048x2,048 could suit some people but large servers have 60,000x60,000 maps that are pregenerated.

 

On the topic of large maps though, I share Euphoric's concerns about what you will be doing with the massive amount of data while simulating this.  You'd bump into so many issues with large maps and performance just due to all the disk read/writes.

 

And with how the simulations work you wouldn't just be able to tag on more land to an already generated map without a huge hassle.

0

Share this post


Link to post
Share on other sites

Popping in here to let everyone know I am working on this slowly; for the past week I have been moving with my wife into our first apartment, but I should be able to resume more substantial development soon!

 

I also had an idea for prospecting in Genisis: riverbed blocks as a unique block which contains the ID of the river from which it came, and you can pan for minerals based on where the river has been, but in doing so the river bed blocks become gravel/sand/dirt eventually, and the existing chunk-based prospecting takes over. This would be a bit complex to implement and require an actual minecraft plugin, but would make prospecting interesting and unique, and give a reliable way to find ore. By panning for minerals, and following the rivers to their source, or until you are no longer getting the mineral, you can find areas, then use the prospecting pick from there.

 

But for now, my actual focus will remain on the actual terrain gen. Thanks again for all the support!

 

In brief reply, as to THUNDERGROOVE's concern, the 2048x2048 render will become more like 32,000x32,000 once finished. The initial simulation produces a rough map which is then refined to much higher resolution.

 

Tsuarok, I expect it to be at a fractional scale compared to earth, 1/4th or 1/10th, generally, as that is minecraft's vertical scale. View distance is an issue, but Optifine (which I consider more or less part of core minecraft at this point) allows for substantial increases in view distance and performance.

 

TyronX, those maps are a small step up from fractal gen, but remain somewhat underwhelming in my experience. They still have very random shapes and mountains are still uniform and bland. As to the developer project, I took a look and most are still fractal-based. But never the less, I appreciate your support! And don't let my comments stop you from suggesting anything else!

 

Euphoric, I am currently looking into several different possibilities for how to manage the data size. It is definitely an issue, but one I think can be overcome. I am investigating the viability of an ECS coding model, possibly using RDBM to hold the non-active data (rock layers would not impact the simulation generally, so it need not be held in memory at all times. most of what is done to the layers are writes, not reads.)

1

Share this post


Link to post
Share on other sites

most of what is done to the layers are writes, not reads.

Can you explain this? This doesn't make any sense. You need both reading and writing in simulation like this. Rock layers affect the total height and can change both up and down. Thus reading is required. 

 

possibly using RDBM to hold the non-active data

This will make it even slower.

 

Not to be rude, but the more you talk about it, the more I think you have absolutely no idea what are you talking about. For example, how are you going to create rock salt stone? Or how are you going to handle ingneous intrusive stone? Or how are you going to create sand (and you are lucky sandstone was removed, because that would be even harder)? Or metamorphic stone? All of those require quite specific situations that you need to simulate. And if you are not going to simulate those, then you cannot reach your goal of "-Realistic ore and mineral generation via geology".

 

They still have very random shapes and mountains are still uniform and bland.

The thing is that most of those projects don't really aim for realism. It all depends on what are you looking for. If you know what the end result should look like, it should be possible to fine-tune the generation to create what you want. At least I think that would be much easier than trying realistic simulation.

0

Share this post


Link to post
Share on other sites

Is this still moving forward?

0

Share this post


Link to post
Share on other sites

If you can get this working reliably, I'd be more than willing to implement it into TFC, with Bioxx's consent.

1

Share this post


Link to post
Share on other sites

Dunk, how are you going to "implement it into TFC", when it is going to be separate application?

0

Share this post


Link to post
Share on other sites

I like the idea of generating continents with realistic margins we see on Earth. However, a great portion of the time the player will be mining, focusing on the immediate area. I therefore strongly recommend to also put emphasis on medium and small-scale structures such as alternating rock layering in sedimentary and metamorphic rock types, folding and buckling of different rock types (e.g. simulation of syn- and anticlines), and of course igneous dykes, calderas, and volcanic cores. 

0

Share this post


Link to post
Share on other sites

Just poking in here to let everyone know I am still alive, and I have not given up on this. More investigation has revealed obstacles which, while they can be overcome, will take time. Additionally, I have been very busy lately between my job and ongoing dental work. Sorry I don't have much more to report.... Oh, I did settle on a language; due to my lack of time to learn advanced usage of C++, and the fact that I have only heard back from one C++ coder, who more or less is waiting on a functional prototype before he jumps in, I will be coding the generator in C# using Xamarin for cross-platform compatibility, and will eventually look at a static compilation for optimal performance (yes, C# can in fact be compiled completely to machine code)

 

Hey Dunk! That's awesome! As mentioned, this will be a separate application, but it will be designed to use TFC blocks as output. What would be awesome is if once initially completed, I could work with you both to make better use of the features it generates. That way, you could add real prospecting where the player follows clues and geology to find where to dig, compared to now, where it's slightly educated guessing. It would be intuitive too; find ore in a river? follow the river upstream to find where it came from!

 

Euphoric up to your bothersome pragmatism I see :P I understand that this will be hard, and with my limitted time it will take quite a while. But I am a firm believer that computers can do almost anything with enough ingenuity.

 

Terex, solid points. To that end I am building out a very general and 'good enough' macro scale generator, so I can put equal or greater work into the micro scale.

 

Thank you all for your support! 

3

Share this post


Link to post
Share on other sites