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

That looks good.

@t0neg0d said:
[java] for (int x = 0; x < gridX; x++) {
for (int y = 0; y < gridY; y++) {
[/java]

Maybe I'm overlooking something obvious but why not simply do

[java] for (int x = 1; x < gridX-1; x++) {
for (int y = 1; y < gridY-1; y++) {
[/java]

Then you wouldn't have out of bounds exceptions. Of course, you would have to make the tile 2 larger on each side and initialize the "border" rows/columns to something, like either pointing straight up or even better "steal" the values from the surrounding tiles if you can generate just those columns (like from a perlin function or whatever).
@jmaasing said:
Maybe I'm overlooking something obvious but why not simply do

[java] for (int x = 1; x < gridX-1; x++) {
for (int y = 1; y < gridY-1; y++) {
[/java]

Then you wouldn't have out of bounds exceptions. Of course, you would have to make the tile 2 larger on each side and initialize the "border" rows/columns to something, like either pointing straight up or even better "steal" the values from the surrounding tiles if you can generate just those columns (like from a perlin function or whatever).


This does work... but the problem I was actually having wasn't the indexes being out of bounds... it was matching these up with the indexes in the normals buffer. I just didn't realize that was the problem... because I'm ditzy. :)

I guess the solution is to start at index gridSize*3+3 and skip 6 indexes every time you reach the outer extent of the y… but since I was not paying attention at the time… dun dun duuuuuun

@jmaasing said:
Maybe I'm overlooking something obvious but why not simply do

[java] for (int x = 1; x < gridX-1; x++) {
for (int y = 1; y < gridY-1; y++) {
[/java]

Then you wouldn't have out of bounds exceptions. Of course, you would have to make the tile 2 larger on each side and initialize the "border" rows/columns to something, like either pointing straight up or even better "steal" the values from the surrounding tiles if you can generate just those columns (like from a perlin function or whatever).


Oh... and the second part... yes, yes and yes. I haven't gotten to the calculating the borders properly yet... but all this info will help me when I get there for sure. This isn't infinite procedural... but I did ad a SimplexNoise function and a parent terrain class. It generate the noise for the entire extend of the terrain and chunks it to 50x50 vert grids. These are stored in 3 different LoDs which you can swap based on distance from the camera.

The big problems I'm working through now are... um:

1. How to properly seed the noise function (which really needs to be replaced with perlin... just due to the results of Simplex looking sorta hokey) so I can create the height maps in chunks as well only when necessary.
2. The dreaded border normals thing... but I like the idea of storing an extra pixel at all borders to make it an automatic function of the normals calculation... but this will rely on actually figuring out the first point.. which I have failed to do correctly so far.

Hmmm… this is very helpful… making think about this more than I wanted too :slight_smile:



A couple things I hope to do with this… which will change how I’m doing everything right now, but should be fun:


  1. I would like to figure out a way of increasing/decreasing the # of vertices depending on the amount of detail at any given point in the terrain. I actually want to do this for more than performance reasons. (point 2)
  2. Use this to determine what type of texturing goes on the terrain tile. The height based method looks terrible to me. But basing it on detail+height would hopefully make for some realistic looking texture splatting that is generated for you.

Well… crap. I have one more question related to this subject.



Is it a bad idea to replace a custom mesh’s buffers and update the model bounds during the render loop without detaching the geometry it’s associated with? Or is this okay to do?

@t0neg0d said:
Well.. crap. I have one more question related to this subject.

Is it a bad idea to replace a custom mesh's buffers and update the model bounds during the render loop without detaching the geometry it's associated with? Or is this okay to do?


Yeah, it's fine.

If it isn’t I’ve got a problem because I’m doing it loads :slight_smile:

@jmaasing said:
Of course, you would have to make the tile 2 larger on each side and initialize the "border" rows/columns to something, like either pointing straight up or even better "steal" the values from the surrounding tiles if you can generate just those columns (like from a perlin function or whatever).


This worked very well... here is a screen cap of 8x8 tiles using using float[][] noise with the extra pixel and offset between tiles working correctly. That was a bit on the confusing side to get working right... but, the normals are calculated in a single pass and looks seamless. The extra values are generated by the noise function and are the same as the next tiles 1,1 etc positions

1 Like

That also shows why the Simplex noise is not a good option for terrain generation >.<

@t0neg0d said:
That also shows why the Simplex noise is not a good option for terrain generation >.<


(Shrug) I think it could work. Generally you want to layer a few noise functions on top of each other at different frequencies anyway. For example, you can get pretty good results just layering two perlin noise calls at different frequencies and scale and just adding them together.

It's a vast area of exploration, really.
1 Like

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.