Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm working on a game that preferably should feature a combination of designed and procedurally generated terrain where the designer specifies in somewhat detailed terms what type of terrain a given area will have (grasslands, forest etc...) and then a procedural algorithm takes care of the rest. I'm not talking about minecraft style biomoes, but rather the game map for a strategy game.

Each 'area' will not take up that much of the screen, and thus be more akin to a tile whose texture is procedurally generated. While procedurally generating terrain textures on the GPU are not that difficult, the hard part is making the borders between them look good. Currently, the 'tiles' are large enough to be visible (due to memory constraints mainly, we are talking planetary sized textures for a game taking place in space and on a continental ground view with seamless transitions between them) and creating good borders between them with an algorithm that is fast enough to be useful has proven difficult. Sampling the n-surrounding pixels and using the combined result did not yield very good borders and was fairly slow on the GPU to boot (ca 12ms for me, that is without any lighting or shading and with very simple terrain texture shaders).

So are there any practical known methods to solve this problem?

Edit:

To clarify, the 'tiles' are there only out of necessity and the whole idea is to make them essentially vanish entirely. This screenshot shows how the terrain looks like right now when the camera is zoomed in about as much as will be possible in the game, with no lighting and very simple texture shaders.

http://s7.postimage.org/y67o03swb/terrain_Sample.png

While the 'internal' borders of each terrain type looks passable, the borders between different terrain types are far too sharp and really exposes the technical details. Shrinking terrain types further is not an option, as that will increase memory usage far too much and it did not actually solve the problem entirely in my test runs.

The good thing is that nearly all GPU resources will be devoted to rendering terrain, so there is room to work there.

Finally, having it done on the GPU both avoids the memory problem and makes it easier to make the terrain morphic without significant runtime slowdowns when large scale terrain changes happen. As the game will have methods to radically change terrain, though only in the large-scale sense, having it be morphic is a requirement.

share|improve this question
2  
Why does it need to be done on the GPU? –  Byte56 Oct 26 '12 at 22:26
    
Don't you want to just draw lines between the tiles? That is, create a grid? –  Markus von Broady Oct 26 '12 at 22:31
1  
You should generate your textures to be tileable. See here: gamedev.stackexchange.com/questions/23625/… and gamedev.stackexchange.com/questions/5224/… –  Byte56 Oct 26 '12 at 22:44
1  
-1 Unclear. What of all that detail is actually essential? Aren't you just looking for how to create tileable textures? –  Anko Jan 25 '13 at 11:29

1 Answer 1

You could have all of your tile procedures utilize some smaller, tiled sections of the same perlin noise. Their borders would be correct so long as your tile generators are able to make the same border heights from the same noise value.

Also, you should not do this in real time on the GPU. You should generate procedural geometry once at asset load time, and keep it persisted. It should remain the same over all draw calls, right? There's no need to spend ms every frame.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.