Infinite Terrain Generator v0.7a

Hey guys, it’s been a fair while since I’ve last posted around here, it’s good to be back and messing around with blender :smiley:

Anyway I’ve created the skeleton of a python based terrain generator, the main feature as of now is the ability to add planes infinitely around the player when they get close to the edge, basic I know but with that main feature done I can can add some extended functionality, mainly:


  1. Save and load terrain position from a file to allow for terrain that’s been generated to be saved (DONE)
  2. Select Vertices at random to place down structures i.e. grass/trees/rocks whilst utilizing the new lod system so the whole thing doesn’t get bogged down and run at 2 fps (DONE)

2. A second python script which modifies the vertices of added planes to make the terrain interesting (which will be the hardest part, I don’t really have any experience with geometry manipulation) (60% complete)
3. Texture terrain based on height(10% complete)

Blend files are below (wasd+mouselook)

(Base version, only features simple terrain gen around player)
v0.1a:[Newer Version Available]

(allows for saving/loading/deleting levels from a outside file)
v0.2a:[Newer Version Available]

(saving and loading is broken but basic structure generation works, script is rather messy and relies on properties a bit too much so I will aim the clean it up in the next version)
v0.3a:[Newer Version Available]

(Structure generation is completely done, all property based too so no messing around with scripts! :smiley: to use it create your mesh i.e. ‘grass’ and place it in a layer seperate to your player and terrain mesh, give the terrain mesh a int property with the same name as your mesh and set the value to the chance of it spawning and done! AND make sure to use lod, because if you go for larger levels you will get massive amounts of lag)
v0.4a:[Newer Version Available]

(Terrain random height is working as well as terrain physics(albeit a bit buggy), still need to fix terrain edge issues)
v0.5a:InfiniteTerrainTest.blend (1.7 MB)

(Terrain random height is switched over to glsl (which I have never used before in my life woooh) based code, physics does not work, neither does random item placement, one glaring issue is that instanced meshes cannot have separate shaders/materials on them, so as soon as a new mesh is “generated” all the instances will change to look like the new one, I’m currently looking into if this is possible to fix)
v0.6a:[Newer Version Available]

(Fixed some issues witihin 0.6a, namely edges of terrain line up but generation is still pseudo-random so this isn’t much of an achievement, a fake AO was also added to the terrain to give it some depth, still working on physics and object placement)
v0.7a:InfiniteTerrainTest.blend (1.53 MB)

Desert Demo using v0.4a (cannot upload file as I don’t have the right to distribute these textures) but using the 0.4 system it is very simple to recreate :slight_smile:

I have ~6 weeks before my final school exams start so I hope to be able to complete all / most of my intended features within that time as I won’t have any time during my testing period to work on this.

very nice, works well in my Linux box!
I’ve moved the player for a while, then pressed the “O” key, then stopped the engine, then opened the file again, and “magically” my previous terrain was there?..
Thank you very much for sharing.

I went back and changed some code, I’m trying to get it so you can load from within the game but I can’t figure out how to delete all the placed pieces of terrain, so the only way to get it to load for now is to exit the game and play again, even restarting through logic bricks doesn’t work so I’ll need to figure something out.

I would like this script to end the terrain behind the player because i just want the dynamic loading.Could you make another version?I think relying on properties is a great idea.Because you could make north, south,west and east properties.And have
four rectangles attached to the player.One for the north property.One for the south property.One for the east property.One for the west property.Then you could have a radar on the player that detects these properties.Then have it so that when the player detects the north property the blender game engine would add to north property and then subtract from the south property.
Then also have it when the player detects the south property the blender game engine would add to south property and then subtract from the north property.Then also have it when the player detects the west property the blender game engine would add to west property and then subtract from the east property.Then also have it when the player detects the east property the blender game engine would add to east property and then subtract from the west property.Then you could parent empties to specific areas of the terrain.Then when all the properties get to specific numbers sets a signal would be sent from player
to a invisible cube that is following the player.Which has the properties on it that are added and subtracted from via a python script.This cube is ended when a specific number set is reached for north,south,east and west properties.Their is a empty parented to this cubes.That spawns a cube that is like it but sends a signal to a different set of empties parented to the terrain via a message actuator.When a different number set is reached.Or sends a signal to the empty attach to it to add
another cube like itself with a empty attached to it.And also itself to end itself if a specific number set is reached.Each
cube added with its empty respond to different number set by adding another cubes with a empty attach to and ending it.These
cubes send messages to empties parented to the terrain.That add building,vehicles,trees,hills and other things.And they end
when the north, south,west and east properties reach a specific number set.
I will make a example for you.

Still working well.
The grass addition is a great one!
Thank you.

I think this is possible, although it might be a big heavy on logic if using near sensors but I should be able to create a workaround with python. Regarding properties I’ve mulled it over and think it might be advantageous to port the script to a blender addon which would allow for easier use with the terrain generation whilst keeping the functionality of properties. I will work on porting the current code towards a blender addon for now and then work on your proposal, expect to see some progress soon :slight_smile:

I would have the terrain do GetDistanceTo(player) every X seconds, and since they are spawned at differing times, it will not ever all happen on any 1 frame :smiley:

Always (30 frames)------------python

import bge
if 'Player' not in own:
    if own.GetDistanceTo(P)>own['Distance']:
        if own.getVisible==False:

You know how to make the wind blow the grass?I think that would be a nice effect to add.

This would work actually, but I need to figure out how to hold a list of the added objects so I can access them separately as currently the terrain is instanced off of a single terrain object and I don’t want that script running off of every added plane

This isn’t actually to difficult to accomplish, it can be done through either a glsl shader or a python script which manipulates vertices, and as the grass is using a lod system it wouldn’t even be too hard on a system to use vertex manipulation, I’ll look into adding something like that in a further release (after I port the script to an addon).

InfiniteTerrainTest.blend (1.51 MB) Here is a example of what i would want it to do.Press w to go forwards.Watch north properties.Plus watch scene.I still need to end the pillars when the north properties reaches a certain number.I will do that later today.I think it would be possible to make a road in the infinite terrain test.blend using the method i showed.It would work even better with python code.

It took me a little bit to understand everything that was going on but it seems like an interesting idea, I was actually thinking of using a chance based system when i finished the addon where you could select a mesh to spawn on the terrain i.e. grass and use the chance of it spawning i.e. 40% to add it onto a vertex on the terrain (rinse and repeat for every vertex in said terrain) but using your method I would be able to spawn in objects at exact locations which is a very nice feature, I’ll play around with it a bit and see if I can recreate it using python

It would be best to have the message sent from the player to be recieved by all added trackers.It would be best to have the message sent from the player to be recieved by all added trackers.Do you understand what I am trying to say?

Yes I understand you :slight_smile: but with large terrain pieces wouldn’t it be perhaps more efficient to have the player send messages to the nearest x trackers? i.e. send messages until 10 trackers are in range, once a tracker leaves said range start sending messages again? that way even with extremely large terrain sizes logic impact would be minimal (I think) so that leaves room for more scripts to run etc…

In the blend one tracker is only allowed in the scene at one time.Like for instance tracker,is not with tracker.001,tracker.002,tracker.003 etc.

bump for 0.6 update :slight_smile:

Are you going fix the physics and random generator?I think i will keep the old one for now until it is fixed.I am making a game
with a hovering spaceship that is a firstpersonshooter that is a survival game.And it will have some of the stuff we were talking about in it.

definitely, but that is only a base version for now so I’m keeping the old “stable” version up whilst I work on fixing the newer one

Looking better with the edges matching.

One major issue with this seems that in no way is it possible to edit instanced objects separately, even when the terrain accessed individually through its id, the mesh manipulation is duplicated through all the objects, it seems like the only way I can make “procedural” terrain would be through the use of a glsl filter, but then there is problems of physics which I currently have no idea about solving :frowning:

and it seems that procedural terrain is impossible through glsl as well :’( whilst I can manipulate vertices of the mesh individually they are all linked back to the same material so no go there, I’m thinking of just cleaning up code for v0.4 and making that my final product, I’m happy that I was able to come this far in terms of programming as I always considered myself a mediocre programmer, heck I even dabbled in some glsl and managed to understand most of it so there is that :smiley: overall I’m kind of sad that engine limitations (at least I’m fairly sure they are engine limitations and not on my half) are holding some of my ideas back but it was fun trying to figure out a solution nonetheless, expect a final release sometime in a week.