[SOLVED] I’m sorry for this in advance… I have a question about uv mapping and normals

I overlay three Perlin values with different scales to generate the height map, I’m very happy with the result.

It is also rather easy to go creative with that and modify the height map for different feelings of the terrain.



One example is to create the splat-map and modify the terrain after the heightmap is generated.

I go over the height map, if the height is less than some constant you adjust the height up, the farther down I adjust more up. This flattens the “valleys” and at the same time you can adjust the “grass”-splat map. So you get grass filled flattened valleys. Like if the dirt had accrued at the bottom of the valley. Pretty simple things but the terrain is still inviting to explore :slight_smile:

1 Like

Funny enough… my current game design would not work with infinite procedural terrain (my fault, of course… but I like where it is going anyways), I’m just interested in the “how it works” aspect. Though, if and when I ever finish up the one I am working on… I would love to throw together a Diablo/Titan Quest-ish type game using this.



Some of the reasons for why it wouldn’t work.


  1. My brain
  2. My server design is specifically geared towards “zones” and would require a complete rework…
  3. My brain

@pspeed @jmaasing

HOLY CRAP! One DOES simply walk into Mordor.







Yep… the multiple passes of noise at different frequencies works wonders… Thanks!

1 Like

Another fun thing, use a Perlin noise to adjust the scales of the other Perlin values, I can play with that for hours. I’ve almost given up getting a game finished since terrain generation is just so much fun :slight_smile:

@jmaasing said:
Another fun thing, use a Perlin noise to adjust the scales of the other Perlin values, I can play with that for hours. I've almost given up getting a game finished since terrain generation is just so much fun :)


Indeed, it is. I have also a very long WIP for terrain generations. The biggest drawdown i currently have is that good looking 'landmarks' are quite seldom.

@t0neg0d a few posts back you are talking about bloxels, is the above terrain generated from a bloxel base?

For 2D fun, this is the map generator I wrote a long time ago that I used to design Mythruna’s base fractals. Up until right this instant, this was a donators only perk… so keep it under your hat. :wink:



This was the original Mythruna forum post from a while back:


As something kind of fun to play with (and because it was easy for me to upload a release), I'm providing Donators "as is" access to the my MapMaker tool. Like an extra thank you.

I wrote this around 2006 and resurrected it to use to design Mythruna's terrain fractals.

You can download versions for the different platforms here:
http://mythruna.com/MapMaker/MapMaker-20120204-Windows.zip
http://mythruna.com/MapMaker/MapMaker-20120204-Linux.zip
http://mythruna.com/MapMaker/MapMaker-20120204-MacOSX.zip

The parameters are probably kind of baffling as they require some understanding of fractals to really know what's going on. But sometimes just adding things and messing with them can show good results.

I'm attaching the config file that most closely resembles Mythruna's terrain. I'm not sure it's the same since I may have tweaked Mythruna's settings in code.

The basic GUI works like this:
You start with a flat terrain at sea level (that's why it's all yellow)
You can add layers that either replace the previous layer or add to it. These layers can also be "affected" by the previous layers.

What is the difference between "additive" and "affected"?
Additive: the values produced by this layers generator are added to the values of the previous. previousValue + thisValue.
Affected: many fractals actually take a 3D coordinated and produce a 3D coordinate. For these layers, "affected" means that it will use the previous layers height as the Z in the next layers 3D coordinate.

Affected is really only useful in fractal-based layers. Additive works for any layer.

If neither is selected then the previous layer is completely replaced (which is kind of a waste).

What do the different generators mean?
Diamond/Squares - One of the original terrain generation algorithms people play with when writing terrain generators. I think I first goofed around with Diamond/Squares in 1993 or so. I had to include but it's not a very useful generator as it has to generate all of terrain at once.
Adaptive Diamond/Squares - Some variation on the above.
Midpoint Displacement - an algorithm similar to Diamon/Squares. These are provided more for completeness and nostalgia. This one is obviously uglier then D/S and has the same down sides.
Multi-Fractal - Now we're talking. The fractals are nice because for any x,y coordinate in the whole world they can instantly give you the height. You do not have to generate all surrounding points. This makes them ideal for an infinite world like Mythruna.
Ridge Fractal - Another cool fractal. Especially nice when affected it turned on. Can be used to add interesting features to a previous layer.
Heterogeneous Fractal - Another fractal. I no longer remember what its specific difference is.
Fractal Sum - One of the better ones. The base mythruna terrain is a "Fractal Sum" layer with a "Ridge Fractal" on top.
Turbulence - a wavy bumpy noise-based generator resembling turbulence.
Perlin Noise - the basic 3D noise that is used by the other fractals. Sometimes useful on its own. For several of the above fractals you could simulate them by layering a dozen perlin noise layers with different settings.
Spherical - generates spherical bumps. This is a useful bottom layer because it will help ensure that you have large above water sections and large underwater sections. It provides large scale underlying variation. Mythruna uses this as its bottom layer to make sure that there is plenty of land and water.
Erosion Operator - filters the previous layer providing some erosion simulated smoothing. This one is not as flexible as the fractal based layers since it requires the surrounding points of a given x,y in order to determine the final elevation... but it's still nice to play with.

Note: Mythruna actually swaps x and y for its terrain. The story of why is longer than I want to go into here... but when you load the Mythruna config file that's probably why the spawn area isn't instantly recognizable. It's there right in the middle you just have to imagine x,y swapped. (north/south is east/west in Mythruna, etc.)

You can kind of see it in this pic:


Hopefully you find some minutes of fun poking around.
3 Likes
@zzuegg said:
Indeed, it is. I have also a very long WIP for terrain generations. The biggest drawdown i currently have is that good looking 'landmarks' are quite seldom.

@t0neg0d a few posts back you are talking about bloxels, is the above terrain generated from a bloxel base?


No... not yet. I'm taking it in stages. Once I finish this up (having issues with LoD atm... the high and medium are being produced correctly, however the lowest detail seems to have a small gap at the outer extremes of the tiles... sigh. I know why it is happening... I think, but it means that I'm not really producing the medium level detail the correct way... just happens that it produces the correct results) I'll start trying to implement marching squares.

Speaking of marching squares... does this method produce overhangs and tunnels as well? Or would I have to look into something else? All I've read about it so far focuses on the implementation but is a little vague on the benefits.
@pspeed said:
For 2D fun, this is the map generator I wrote a long time ago that I used to design Mythruna's base fractals. Up until right this instant, this was a donators only perk... so keep it under your hat. ;)

This was the original Mythruna forum post from a while back:


Can't even begin to tell you how much I appreciate this. For more than one reason, too. I've also been playing around with procedural texture generation using shaders, but have a VERY limited understanding of fractals.

Maybe someone else can help me figure this one out…



Here is a screen with 3 LoDs… the first and second are correct, only because of this…



Someone defines the number of verts in a grid…

I do a mod on the # of verts defined and if it’s not an odd number, I bump this up by one

Then I knocking out every other vert. Sooo…

floor(gridSize/2)+1



This works fine for halfing the number of verts… but not so well after that. My brain is mush… what’s the solution for this? >.<



Nm… It was the way I was dividing it up…I’d need to divide by 2 and then by 5 for the next level of detail down.



EDIT: And apparently the # of verts per grid needs to be divisible by 10. But, that’s good enough for me… here it is using 20, 40 & 60 verts +1 per grid.







1 Like

wow, very nice!

@t0neg0d said:
No... not yet. I'm taking it in stages. Once I finish this up (having issues with LoD atm... the high and medium are being produced correctly, however the lowest detail seems to have a small gap at the outer extremes of the tiles... sigh. I know why it is happening... I think, but it means that I'm not really producing the medium level detail the correct way... just happens that it produces the correct results) I'll start trying to implement marching squares.

Speaking of marching squares... does this method produce overhangs and tunnels as well? Or would I have to look into something else? All I've read about it so far focuses on the implementation but is a little vague on the benefits.


A bloxel base should allow overhandgs and tunnels, however, the currently used 'common' approach (at least from the papers i have read) is that using a hightmap based terrain without holes and overhangs is so much faster when it comes to physics that most games simply cut holes in the mesh and add a cave mesh.

How does your terrain look in non wireframe mode? On my version using GPU tessellation i had visible holes where higher quality mesh meets lower quality mesh:

http://image-upload.de/image/cypGVS/259fc0d52c.png

Depending on the targeting platform i can tessellation for hightmap based terrain for me is the best way to do. Nearly unlimited detail in the near and smooth transitions to the far, all at very low cost. If there is interest i have no problems to share my tessellation stuff so there would be a base for starting. (It requires adding tessellation support to the core, i can publish a patch for the current nightly too)

http://www.youtube.com/watch?v=x6NxrYGilX4&feature=plcp
2 Likes
@zzuegg said:
A bloxel base should allow overhandgs and tunnels, however, the currently used 'common' approach (at least from the papers i have read) is that using a hightmap based terrain without holes and overhangs is so much faster when it comes to physics that most games simply cut holes in the mesh and add a cave mesh.

How does your terrain look in non wireframe mode? On my version using GPU tessellation i had visible holes where higher quality mesh meets lower quality mesh:

http://image-upload.de/image/cypGVS/259fc0d52c.png

Depending on the targeting platform i can tessellation for hightmap based terrain for me is the best way to do. Nearly unlimited detail in the near and smooth transitions to the far, all at very low cost. If there is interest i have no problems to share my tessellation stuff so there would be a base for starting. (It requires adding tessellation support to the core, i can publish a patch for the current nightly too)

http://www.youtube.com/watch?v=x6NxrYGilX4&feature=plcp



Man... the tessellation work is awesome! I would love to have a look at that for sure. Right now, there is very little gap in the tiles (depending on how you set settings, of course... and when I say little... I mean that it is livable and not easily noticed... the drop from mid level detail to low is the biggest offender due to). Let me grab a screen of wire / white with normals and textured. One sec...





And one from higher above the ground for comparison





Um... Imgur uploads my images to 101%... now THAT is going above and beyond... WTF is the extra 1% O.o

The gaps might be more apparent on light terrain with a black background.



I used to worry about complex stitching in these cases but it turns out to be unnecessary. Years ago, when I was looking into OpenSceneGraph’s terrain paging I noticed that all that happens there is that each tile has a skirt around it that simply extends the texture down some amount. Like, it goes from the edge straight down and just stretches the texels that are on the edge. Extremely easy to implement and I never knew it until I looked below the terrain… so it’s very effective. It’s also 1000x easier than trying to dynamically stitch LODs together.



I have no idea what JMEs terrain does in this case. Maybe similar. (shrug)

Oh… you mentioned the version on the GPU… I take it that the other is CPU based,… yeah… I’m brilliant >.< How is the performance on the CPU version? I’d be a little worried about collision detection and such running it on the GPU… though, I’d be a heck of a lot more comfortable writing it via a shader than the other…

The collision mesh is (usually) not the same mesh you are seeing on the screen… many times a crude approximation will give you good enough collision accuracy and be a lot cheaper than if using the visible mesh…

Just wanted to share the outcome of using the skirting idea. It works awesome.



http://youtu.be/if8qDwyhzx4

3 Likes
@t0neg0d said:
Just wanted to share the outcome of using the skirting idea. It works awesome.

http://youtu.be/if8qDwyhzx4



looks very good indeed

It seems counter-intuitive at first, but believe it or not you do not need to bevel the skirts. Having them go straight down works just as well.



Reason: horizontally (2D map space) the terrain is already 100% connected… all of the gaps are vertical (elevation).

1 Like

In fact if the join happened at a really steep point (i.e. cliff) then having them non-vertical could cause a problem…