[Case study]Procedural Generation Computer technology

[lysan]

Terrain Generation using Procedural Models based on Hydrology
http://arches.liris.cnrs.fr/publications/SIG2013.html

http://www.youtube.com/watch?v=JCsj0v-wmIM&list=PLW6Sw84oyq6I3GdK2tlbEf5TQHx0sYoHb

Making things with Math!
Steven Wittens

http://www.youtube.com/watch?v=Zkx1aKv2z8o#t=10

I hope FDEV are following this too

 

[Iain M Norman]

Terrain Generation using Procedural Models based on Hydrology
http://arches.liris.cnrs.fr/publications/SIG2013.html

http://www.youtube.com/watch?v=JCsj0v-wmIM&list=PLW6Sw84oyq6I3GdK2tlbEf5TQHx0sYoHb

I hope FDEV are following this too

That depends on how quickly those river paths and erosion things can be calculated.

For ED the terrain building PG work will have to be done either in real time, or somewhere close to real time. They can't be calculated and stored for 4,000 billion planets ahead of time.

 

[Windscreen Smudge]

That depends on how quickly those river paths and erosion things can be calculated.

For ED the terrain building PG work will have to be done either in real time, or somewhere close to real time. They can't be calculated and stored for 4,000 billion planets ahead of time.

On a geological scale, once a year is typically accurate enough for your basic eroded terrain.

You could make it once a month or so if you wanted to get really tetchy about it, I suppose.

 

[lysan]

That depends on how quickly those river paths and erosion things can be calculated.

For ED the terrain building PG work will have to be done either in real time, or somewhere close to real time. They can't be calculated and stored for 4,000 billion planets ahead of time.

Todays PC's should be able to process all the calculations needed to do the task.

 

[Windscreen Smudge]

Todays PC's should be able to process all the calculations needed to do the task.

You're forgetting the generation of historic data going back hundreds of millions to billions of years for each planet.

Stuff like this is best calculated by racks of GPU's or ASICs/FPGA's.

Neither of which is hard to do, if you have people trained to do so.

 

[Scourge]

On a geological scale, once a year is typically accurate enough for your basic eroded terrain.

Soo 400,000,000,000/365= 1,095,890,410.96.

So the question is it reasonable to calculate the almost 1.1 Billion planets worth of geologimiwatsits a day?

 

[Windscreen Smudge]

Soo 400,000,000,000/365= 1,095,890,410.96.

So the question is it reasonable to calculate the almost 1.1 Billion planets worth of geologimiwatsits a day?

A year, or a month, and with the right hardware it goes very quickly.

And cheaply, too, a good ASIC setup will consume a small fraction of the electricity of a few racks of GPU's.

FPGA's may be there in a year or two, it all depends on whether that industry bombs again or not.

 

[lysan]

Some of these techniques look really astonishing.

http://liris.cnrs.fr/~apeytavi/

BTW not all the planets are rocky worlds with an atmosphere so the PG would be limited.
Water worlds could be and expansion until we are able to be submerged.

I don't know how much CPU/GPU power there would be needed, however this could be done in a GPU cloud environment? The info we get from FD is very limited

 

[Windscreen Smudge]

Some of these techniques look really astonishing.

http://liris.cnrs.fr/~apeytavi/

BTW not all the planets are rocky worlds with an atmosphere so the PG would be limited.
Water worlds could be and expansion until we are able to be submerged.

I don't know how much CPU/GPU power there would be needed, however this could be done in a GPU cloud environment? The info we get from FD is very limited

This stuff is simplistic, and would only take a single GTX 480 a few seconds for anything you find on that page.

Video games are highly inefficient because the visual image has to be calculated hundreds (you don't see all of the frames created by the card, many are discarded) of times a second. An algorithm for procedural generation takes a small amount of that processing power since the visuals can be applied after the process.

 

[Iain M Norman]

It needs to be done real time or close to, not because it can't be done slower, but because if you did it in advance, where on earth would you store 4,000 billion planets worth of terrain data!

Take a silly low figure like 1 MB for a whole planets terrain data.

That alone is 4 million terabytes!

So the terrain will need to be calculated by the client either in a loading screen, or streaming in the generation in a predicting where you're going next kind of way, or realtime. Either way it needs to be milliseconds to seconds, not minutes or hours.

 

[lysan]

This stuff is simplistic, and would only take a single GTX 480 a few seconds for anything you find on that page.

Video games are highly inefficient because the visual image has to be calculated hundreds (you don't see all of the frames created by the card, many are discarded) of times a second. An algorithm for procedural generation takes a small amount of that processing power since the visuals can be applied after the process.

So, it would be easy for FD to make PG like that in the game?
For me this would be great as I played SPORE sometime ago, the game was not that great, however the PG was quite clever.

 

[Windscreen Smudge]

It needs to be done real time or close to, not because it can't be done slower, but because if you did it in advance, where on earth would you store 4,000 billion planets worth of terrain data!

Take a silly low figure like 1 MB for a whole planets terrain data.

That alone is 4 million terrabytes!

So the terrain will need to be calculated by the client either in a loading screen, or streaming in the generation in a predicting where you're going next kind of way, or realtime. Either way it needs to be milliseconds to seconds, not minutes or hours.

Or it could be calculated on a separate server set up specifically for the process whenever a player enters a previously undiscovered system. It could be done system by system, or by every 1000 cubic light year chunk (the largest grid layout when looking at the map).

Player jumps into the system, and the request to procedurally generate the planetary surfaces of nearby systems is queued, by the time the player jumps to the next system they're ready for viewing and will be stored for anyone visiting thereafter.

And you should go into Elite's folder and look at some of the OLV's used for the procedural generation. Currently the largest file I'm spotting is for massive stars at 683kb.

Remember. This started with 32kb.

 

[Armour]

Given Mr Braben's dismissal of most other games' attempts to do PG of planets as coloured heightmaps, I too would hope he has some tricks up his sleeve. Procedural generation can be done in multiple dimensions. Ken Perlin's site has some examples listed. Also, this video shows 4D noise generation for what looks like cloud modelling. If there are algorithms available that can use the coordinates in space and time as the seed for a given planet, then hopefully there's no need to store anything as the correct meshes/textures/other maps can be created anew each time the planet is visited. If the age of the planet is also generated via a PRNG plus some domain-specific, knowledge-based code, perhaps that age could be used as part of the input to the PG functions, so that the planet might look age-appropriate?

 

[Windscreen Smudge]

Given Mr Braben's dismissal of most other games' attempts to do PG of planets as coloured heightmaps, I too would hope he has some tricks up his sleeve. Procedural generation can be done in multiple dimensions. Ken Perlin's site has some examples listed. Also, this video shows 4D noise generation for what looks like cloud modelling. If there are algorithms available that can use the coordinates in space and time as the seed for a given planet, then hopefully there's no need to store anything as the correct meshes/textures/other maps can be created anew each time the planet is visited. If the age of the planet is also generated via a PRNG plus some domain-specific, knowledge-based code, perhaps that age could be used as part of the input to the PG functions, so that the planet might look age-appropriate?

3.8 billion years old and sitting on the surface of Earth.

And that's the problem. Even on a geologically unstable planet like Earth parts of the crust can stick around and weather for billions of years. Things get complicated when you have tectonic activity. Some of the earth's crust is only a few million years old, and some of it is almost as old as the planet itself.

Geologically stable planets would work fine with applying a default age algorithm to, though, as long as the algorithm takes into account when the planet became geologically stable.

 

[lysan]

Question would be how must of this are simulated?

 

[Armour]

3.8 billion years old and sitting on the surface of Earth.

And that's the problem. Even on a geologically unstable planet like Earth parts of the crust can stick around and weather for billions of years. Things get complicated when you have tectonic activity. Some of the earth's crust is only a few million years old, and some of it is almost as old as the planet itself.

Geologically stable planets would work fine with applying a default age algorithm to, though, as long as the algorithm takes into account when the planet became geologically stable.

Well that would all be part of the algorithm, wouldn't it? Anyway, nobody expects scientifically-perfect data being generated on the fly, taking into account all sorts of outliers and edge cases. We're talking about content that looks good enough, and feels right enough, that the majority of players are able to suspend their disbelief.

If every geology student wants to poke holes, let them have their fun. It's a game, after all. I don't have to listen, the same as I don't have to listen to experts telling us how terrible some sci-fi film is because they got some basic principle wrong or something. I'd like it to be reasonably realistic, but I don't expect every atom to be simulated correctly - even if Hello Games pretend that's what they are doing.

 

[Windscreen Smudge]

Well that would all be part of the algorithm, wouldn't it? Anyway, nobody expects scientifically-perfect data being generated on the fly, taking into account all sorts of outliers and edge cases. We're talking about content that looks good enough, and feels right enough, that the majority of players are able to suspend their disbelief.

If every geology student wants to poke holes, let them have their fun. It's a game, after all. I don't have to listen, the same as I don't have to listen to experts telling us how terrible some sci-fi film is because they got some basic principle wrong or something. I'd like it to be reasonably realistic, but I don't expect every atom to be simulated correctly - even if Hello Games pretend that's what they are doing.

But that makes it an algorithm with many more steps than an algorithm that would just take a predetermined aging model and apply it to a static planet. Billions more, in fact. So it makes a difference.

And it's not about nitpicking. Hydraulics, tectonic activity, atmosphere and solar influences have a directly noticeable and fundamental impact on the basic appearance of a planet. Get the fundamentals right and everything will come out gorgeous, get it wrong and everything will look silly.

 

[cpbtrading]

But what about player interaction with the environments. Does damage get generated 'always' after the initial damage has happened, ie does it remain.

A war on or around a world of some type, would mean damage to cities etc.
Does that damage generate or will the PG simply generate the first view using the initial tools it had.

If it does indeed generate it as it was before, then that would be very un-realistic.

Also would every player 'see' that damage in MP, or do players see different views.
??

 

[Armour]

But that makes it an algorithm with many more steps than an algorithm that would just take a predetermined aging model and apply it to a static planet. Billions more, in fact. So it makes a difference.

Not much of a difference. You just ensure that the results the algorithm produces look somewhat like what you might get from a much more complicated and accurate method. That's what real-time coding for games and/or the demoscene is based upon, after all, cheating. You've got 2 choices. 1) Show them one you made earlier and pretend you made it up on the spot, or 2) Show them one you knocked together on the spot that looks real if you squint, then make sure that they have to squint.

And it's not about nitpicking. Hydraulics, tectonic activity, atmosphere and solar influences have a directly noticeable and fundamental impact on the basic appearance of a planet. Get the fundamentals right and everything will come out gorgeous, get it wrong and everything will look silly.

Or you use a lot of approximation and false "detail" passes that make what you are generating appear/behave somewhat like you would expect from a simulation, but at a much lower cost in processing terms.

I'm guessing that most cloud generation is done with simple noise algorithms, not a full simulation of the water cycle. But if it appears to be cloud-like, does it matter?

 

[Armour]

But what about player interaction with the environments. Does damage get generated 'always' after the initial damage has happened, ie does it remain.

A war on or around a world of some type, would mean damage to cities etc.
Does that damage generate or will the PG simply generate the first view using the initial tools it had.

If it does indeed generate it as it was before, then that would be very un-realistic.

Also would every player 'see' that damage in MP, or do players see different views.
??

I'm guessing that changes will be saved on a general level, but will be quickly brushed away over a shortened period of time so that storage doesn't increase exponentially because you like destroying cities.