-1
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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