I am looking for procedural terrain generation resources

#1 I remember seeing someone develop something like this, but I am not sure if they had to do a custom terrain object or not.

Do you want to eliminate level loading or would that be okay? How complex do you want your terrains to be? What kind of game? If it is a flight sim then you could probably use less detail on the terrain versus an RPG which more detail on the terrain would be better.


This is something I am interested in, but I have not worked on it in a while.

#2 Well i would like to try an approach where level loading is sort of "put aside"

Basically where the game world is deterministically generated and the actual world environment become "irrelevant" to the engine.

Basically, player spawn at XYZ position, the client and the server will generate an identical model of the terrain, roads and trees surrounding the player.

Something simmilar to how minecraft generate the boxel chunks around a player, at the difference that here it's not a voxel and it's not ment to be modified.

#3 Alex Fritz(http://www.garagegames.com/account/profile/127248) was working on procedural terrain generation.he has a working procedure for ogre.
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=49849&p=456774#p456465

it is bout 4 month since last i have heard from him.he was working on t3d integration.
very helpful person.but most of his writings seems greek to me.

[edit]
konrad kiss have used procedural terrain/zone generation for their MMO(www.xenocell.com/gameplay/)

#4 With the existing terrain in T3D you could create random height maps to deform a terrain object. You will have to take some liberties to make it playable. You might look into fractal algorithms for generating the height map. There may already be terrain generation algorithms available as well.

Then you would need to do some texture placement based upon rules like the climate zone (desert, temperate, arctic, rain forest, etc) for vegetation placement. You will need to be able to lay foundations for buildings and roads as well. Something that goes through the terrain and flattens areas. In addition you will need to determine safe spawn locations for players.

All of this could be done from a server 'seed' value. That 'seed' value would be shared with clients so that the exact same environment is generated for all players. Otherwise you will need to have the server generate the environment and the clients download the resulting map. In order to make it seamless the terrain could be generated in the background while the players are doing something else. That assumes the game knows where the next location is that will be traveled to.

This is something I have had in the back of my mind for a while. I did not plan on creating custom terrain objects, but to use the existing terrain block. I was planning on using procedurally generated terrain, towns, castles, dungeons, etc. The idea was to allow the game to be massive. This would be similar to Dagger Fall by Bethesda. Another idea was to use satellite data so players could literally choose the location they wanted to visit. The problem with that is that the satellite data is not necessarily small or easy to download on the fly.

I think all this could be done using TS to start. Later for speed parts might make sense to do in C++.

Edit:
Okay, the existing TS code might not let you generate heightmap data or images. So there may be some C++ code needed to do that. That might need more attention than the rest of the capabilities.

#5 Forgive me if the following makes little sense. I'm an artist and this is probably way outside my realm of knowledge, but I'll put it out there anyway.

You could possibly have a groundCover object that belongs to a greyscale range of pixels (like 0-24, 25-123, 124-255) and have it proceduraly paint onto the areas of the terrain that are that tone on the heightmap. You could possibly have a plugin app that generates basic Perlin heightmaps and voila! Rocks exactly where they're meant to be, and all done procedurally and accessed via script.

Something like that, at least.

#6 I'm more an artist than a coder too, and i know nothing about procedural content generation, so I guess there is a learning curve there :D

Okay so all i need is some kind pf process that will procedurally generate the .ter files and then inject the terrain blocks into the engine on runtime based on player position, lets say a 3x3 terrain grid, and as the player move from grids to grids, destroy the previous grid tile and generate new ones.

Am i right?

#7 @Kyrah,
I am hoping it can be done from script. I was thinking you could use a greyscale bitmap to deform the terrain object and it would generate everything you need. The trick is building that bitmap I think. Maybe later this week I will take a closer look at this. This is something I do want to have working as well.

#8 If you can write a valid .bmp file from TorqueScript you can use it as a terrain heightmap. The trick would be writing that file in the first place! I don't remember if TS has facilities to do raw file writes, which you many need to do for header data, but you could possibly fake this by figuring out the ASCII values for whatever byte patterns you need.

#9 Or figure out what the function that does the importing of a height map actually requires. It might make more sense to do direct terrain object deformation. Kind of like the editor does. That might be able to be done in script now.

#10 And the function that exports height maps - it's in there, can't remember where though. You can find it in the editor's file menu....

#11 Yeah, the editor creates a new terrain by calling:

%obj = TerrainBlock::createNew( %terrainName, %resolution, %materialName, %genNoise );

The implementation of that is in engine\source\terrain\terrImport.cpp

It already does some procedural generation - if %genNoise is true, it procedurally generates a terrain using Noise2D fractal brownian motion implementation. That would be a good place to start, replacing the fbm with your own stuff.

If I remember correctly, TGE had much better terrain generation features than T3D, you could choose different noise types, erosion, procedural texture placement etc. That stuff might still be hidden away in T3D but not currently used.

#12 Ooh, I can see adding another optional params that describes the 'type' and possibly source data. Also, if there are not already maybe some calls on the block to modify the data.

#13 Most interesting! Feel free to share a proof of concept anyone! Even if it's just pretty pictures :D

#14 I took a gander at the terrImport file and found the genNoise option includes about 38 lines of code. The code is not complicated at all. I bet with a little thought an option could be included to allow a script to modify the terrain data. It is just a grid of data. If this part were to be exported to a script function, or an entirely new terrain generation function with script hooks it would be easy for people to modify or generate custom terrains procedurally.

Now that would just be the terrain heightmap and object creation. There would still be a need for functions (if they don't already exist) to be built/used to tweak textures and the like. However, I think the original question was about feasibility. Guy was right on track with his suggestion about the createNew function.

Some things I noticed. The "seed" value is fixed. So just allowing that to be changed would generate more variety on the generated terrains using the existing noise functions. Also, there are other options for random terrain generation. There is one in there called rigidMultiFractal. The docs says it should generate more mountainous terrains. So it sounds like there may be some other goodies lurking in there.

Anyway, I can't get on this now. But down the road a bit I will be looking at this again. Kyrah, let me know if you need help with this. If there is a pressing need I can look at it sooner. I am willing to look at this because this is something I will want later on. I think this may be a good candidate for a feature that gets added to the CE. It has the potential to add a lot of value to the engine.

#15 The createNew function uses the Noise2D class which actually seems to include a lot of useful stuff. You can use these functions for the generation of the actual terrain or you could use them to control the placement of objects/features.

Noise generation algorithms:
Noise2D::fbm (fractal brownian motion - rounded terrain features)
Noise2D::rigidMultiFractal (sharper terrain features)

Post processing:
Noise2D::erodeHydraulic (simulated fluid erosion)
Noise2D::erodeThermal (simulated thermal erosion)

Utility:
Noise2D::turbulence (I think this is Perlin noise)


For applying textures to the terrain procedurally, Konrad's rule based layer distribution resource does 95% of that for you. The only part left to make it completely human free is to write some simple methods for specifying a 'texture set' to use on the terrain and have it generate the masks for them.


Also, don't forget about the fxFoliageReplicator and fxShapeReplicators which have been assigned to the scrap heap without a functionally equivalent replacement.
Both of those classes are procedural generators - give them a seed and some constraints and they will cover your world in shapes and billboards. There's nothing stopping you from taking them one step further and placing the replicators themselves procedurally.
You will need to fix the issue with phantom collisions due to the order that the replicators are ghosted, but that's trivial to do.


For roads and rivers, the shape of those are all controlled by the position and rotation of nodes. A few supporting console functions should be all that's needed to allow you to create them procedurally.


There's actually a surprising amount of stuff in the engine already that can be leveraged for this. There used to be even more. In the worlds of Tom Spilman "We removed the old TGEA procedural terrain generation to get a clean slate and allow T3D terrain to advance without being limited to 100% backwards compatibilty with old systems." It's a shame that the 'advance' was never made :(

#16

Quote:You will need to fix the issue with phantom collisions due to the order that the replicators are ghosted, but that's trivial to do.

This is greek to me, please explain.

Also, I am going to work a bit on this over the weekend. I really want to see what can be done. I figure I will check it out while everyone's interest in piqued.

#17 @Frank, this thread.
The replicators are created on the client in reverse order to how they were created on the server. The result is that the placement of the replicator objects is not guaranteed to match up between client and server.

#18 The quick fix that I use:
in engine\source\T3D\fx\fxShapeReplicator.cpp,
function:
DefineEngineFunction(StartClientReplication, ..............
change

for (SimSetIterator itr(fxReplicatorSet); *itr; ++itr)

to

for (SimSet::iterator itr = fxReplicatorSet->end()-1; itr >= fxReplicatorSet->begin(); --itr)

#19

Quote:The only part left to make it completely human free is to write some simple methods for specifying a 'texture set' to use on the terrain and have it generate the masks for them.

I believe we could create a 'climate editor' so that we could set up various texture sets. Obviously that would require some source changes (I have barely any knowledge of what I'm saying here) but surely that'd be the most user-friendly solution? Or even adding the functionality to the current Terrain Editor? That'd make this engine a beast in the terrain generation arena.

Quote:Noise2D::erodeHydraulic

I want this. It'd allow us to separate flows on the terrain from the currently active 'climate' to be textured independantly from the terrain. That is, we could 'texture' the flows with the river editor. That way we could (possibly) procedurally generate the actual rivers.

I'm starting to get carried away here, imagining an editor that lets us choose a climate, terrain type and vegetation density and voila, instant landscape. Of course then I'd be out of a job, but that's irrelevant at this stage.

#20 I added a console method to serialize SimObjects to text. This would allow generating missions completely in memory.
www.garagegames.com/community/resources/view/21813

Then from here I can start looking at the terrain generation functions and how to expose the terrain height map to script. I am thinking we will want some simple deformation commands outside of terrain creation. These would be similar to deformation done by the editor except done in script completely. They would only be on a memory object as well. I think active "in mission" deformation would bring a host of issues with networking so I am going to avoid that. I will just focus on the generated mission in memory for now.