Dwarf Fortress is about the closest I've seen to what you are talking about. The procedural world generation algorithm generates rock layers, water tables, erosion, etc. in order to populate a life-like world. Pretty cool stuff.

Dwarf Fortress is about the closest I've seen to what you are talking about. The procedural world generation algorithm generates rock layers, water tables, erosion, etc. in order to populate a life-like world. Pretty cool stuff.

Seconded. It also includes real-world minerals, so instead of "Zinc Ore", you find "Sphalerite". Before I played DF I didn't realise there were so many different metal-bearing minerals.

If you read the book Texturing and Modeling: A Procedural Approach, in Chapter 14, F. Kenton Musgrave talks a bit about the differences between teleological and ontogenetic modeling. Specifically, teleological is "a) the study of evidences of design in nature... c) a doctrine explaining a phenomena by final causes" whereas ontogenetic is "based on visible morphological characters". In essence, it is the differences between generating, say, a terrain using precise modeling of real-world tectonic and erosive forces, as opposed to modeling a terrain using random crap that happens to create something similar to what you are trying to achieve; ie, noise fractals and other techniques.

It's a discussion that has been occurring for a long time now; since the earliest days when modern graphical techniques were being pioneered in the 70s and 80s. While advances in hardware and computation speeds have been astounding, there are still very real, practical limitations on the available computing power. There are other constraints as well, especially in a game, where the (im)patience of the player is the key constraint. The aforementioned book has a number of quotes that I find to still be relevant, even in this day and age.

"Scientific models, or 'physical' models in computer graphics parlance, do not generally map well into efficient algorithms..."
"When you use a physical model... you often waste time computing the answers to questions about which you care not."
"Ontogenetic models tend to be--indeed ought to be--simpler and more efficient, both in programming and execution time, than corresponding physical models."

I remember once generating a new world in Dwarf Fortress. I love that game, but sweet hell was that generation process an onerous and frustrating expenditure of time. It even "failed" a couple times, forcing me to restart the process. I can only imagine how much longer it would have taken to generate it using more physically accurate processes, rather than the crude and error-prone processes being used.

Of course, for offline tools (such as those employed in making a game like Skyrim), I am certainly very much in favor of more accurate simulations. However, you also have to understand that extreme "realism" might ultimately run completely counter to the core idea of games, which is fun. Certainly, detailed and precise physical models are kind of cool, but you have to wonder if it is worth pouring hundreds of hours of design and execution time (detailed physical models can be VERY computationally expensive) for something that the vast majority of players are just going to charge across, guns blazing, far more intent on gibbing the enemy noobs than in studying the terrain around them for physical accuracy. That time might have been better spent adding more areas or maps, or in other ways enhancing the gameplay and "fun".

Eventually, I think, a team can abstract away a lot of the design for the physical processes, and amortize that expenditure across several projects, but it will always be a balancing act, and one in which fun and gameplay must always take precedence over physical accuracy. I think it is a worthy goal, what you want to achieve, though. I do recommend that book, though. It's a very enlightening read.

My feeling is that physical processes are best suited to generating finite sized play areas at design time. Unlike fractal methods, they can't be easily tiled and generated at runtime from a seed, so "infinite" play areas are out.

Not necessarily "out", geological effects decay with distance, so you might be able to dumb down simulation more and more as the distance to the player increases, eventually stopping all simulation at a given range. Other persistent effects like erosion with time are a problem though, since they would have to be started all over again if the player changes region. They could be faked though, perhaps.

This isn't trivial though, unlike fractal methods... I agree that this would work better on a limited map - but the map needs to be big enough to be convincing.

I feel like the teleological mindset of modelling would have to begin in a certain genre like you mentioned. There is no way a normal run and gun sort of genre, (or gamer for that fact) would stop and admire the nature of the region. It would have to be on a much more grand scale. It brings me to mind of many fantasy authors out there. Tolkien for instance almost had the entire region of Middle-Earth naturally and scientifically accurate down to a tee before any of the Fellowship ventured through its valleys, swamps, or mountain tops.[/quote]
I'm picturing an adventurer, fully clad in hardened steel armor, reaching the edge of a huge cliff and revealing dozens of squared miles of incredibly physically accurate snow-covered terrain, with misty swamps visible at the horizon, complete with the loud rumbling of the wind as it gushes through the trees, and the sound of little rock pebbles tumbling down the surrounding cliffs.

Some aspects of change could be slow-paced enough that you wouldn't have to spend game time on them every single frame, or the updates could be spread out across multiple frames. For example, consider hydraulic erosion. The Navier-Stokes equations for hydraulic flow and erosion have already been approximated on the GPU,. That could be an on-going task that is incremented in small bits each frame, and could even be implemented on the GPU using OpenCL if desired. Thermal erosion could be done in a similar manner. As Bacterius indicated, though, it would be tricky having "persistent" erosion in a large-scale world. Procedural methods compress very well; you can represent an entire world using a single integer seed to give to the generator. However, when changes are imposed upon the generated data set, there needs to be a record made of those changes stored to disk. Something like erosion causes changes across the entirety of the data set, which can result in a very large chunk of change data that must be stored to disk in order to maintain persistence. This could easily result in hundreds of gigabytes of data, even compressed, with a very large world.

BTW, someone earlier in the thread made mention of a plate tectonics thread. That thread is http://www.gamedev.net/topic/623145-terrain-generation-with-plate-tectonics/ and it looks mightily interesting. The guy even posted a link to source code. I haven't fiddled with it yet, but I might have to download it and tinker for awhile. This thread has got my brain fired up for procedural stuff again.