Another Planet Renderer

It is purdy, but the seam I’m seeing is making me twitch. :wink:

Wow!!! O_o

Wow!! photorealistic images right there

@kwando said: Wow! Very impressive! =)
@nehon said: Wow gorgeous!
@jmaasing said: Impressive. Looks really nice.
@kles4enko said: Wow!!!!! O_o
@wezrule said: Wow!! photorealistic images right there

Thanks!

@madjack said: It is purdy, but the seam I'm seeing is making me twitch. ;)

Yea, any remaining seams are caused by the normal maps. I create them by running a sobel filter on the heightmaps I generate and this involves the sampling of the 8 neighboring pixels around the pixel in question. I can probably fix this by rendering a 258x258 heightmap instead of a 256x256.

@toolforger said: The ridges still "don't look right". Otherwise, this seems to be getting better by yet another order or magnitude. Very impressive.

Thanks, what do you mean about the ridges though? I can probably run erosion on them to make it more realistic…

@mifth said: @okelly4408 That's super cool and realistic! Will the project be opensource?

Definitely (eventually)

Very nice!

Runs poorly at low altitude on my laptop (NVS 5200M GPU). My guess would be the heightmap generation. I’ll have to try it on my faster desktop.

I wonder if it would make sense to compute heightmaps CPU side where you can leverage multiple threads and caching… I dunno…

@aaronperkins said: Very nice!

Runs poorly at low altitude on my laptop (NVS 5200M GPU). My guess would be the heightmap generation. I’ll have to try it on my faster desktop.

I wonder if it would make sense to compute heightmaps CPU side where you can leverage multiple threads and caching… I dunno…

Yea, if you want you can download this version: here . With this version you can press “9” to increase the level of detail sensitivity (increasing performance while decreasing visual quality) and “0” to decrease the lod sensitivity (decreasing performance while increasing visual quality). I will make a gui one day…
I did a few tests a while back comparing the cpu and gpu performance in terms of creating heightmaps. I found that as the size of the heightmap grew the time that the cpu took to compute it greatly increased while the time needed for the gpu heightmap remained at around 2 ms.

@okelly4408 said: Thanks, what do you mean about the ridges though? I can probably run erosion on them to make it more realistic...

The ridges seem to be quantized: angles at multiples of 60 degrees, distances also seem to often be a multiple of some distance.
Erosion is going to cover that up a bit, but it’s still looking more artificial than it should to me.

You could to a Fourier transform of the heightmap. If it’s as random as the original, you’re fine, but if you see spots and bands, that’s the prevalent repetitive terrain variation.

One of the effects that can cause this is scaling.
Fractal terrain generation is usually a process of halving the mesh and assigning a randomized height value, then repeat. The randomization is done with a factor that depends on the neighbour mesh vertex distance; as far as I recall, that factor depends on whether you have a square or triangle mesh, and if you use multiple intermediate points on each detail step I think the number of points goes into an exponent.

Okay, I gather you’re doing erosion, that can create regularities as well, depending on how it’s done.

@toolforger said: Fractal terrain generation is usually a process of halving the mesh and assigning a randomized height value, then repeat. The randomization is done with a factor that depends on the neighbour mesh vertex distance; as far as I recall, that factor depends on whether you have a square or triangle mesh, and if you use multiple intermediate points on each detail step I think the number of points goes into an exponent.

There is one tiny class of fractal that requires sampling the neighbors in this way (see diamond-squares) but it is by no means the only way. The best terrain fractals in fact don’t do this at all. (best at least partially because they don’t and partially because they don’t suffer from the imposed regularity of the neighbor sampling) For example, in Mythruna I can get the elevation for any point in the world just by running it through the stack of fractals. It’s just math.

To the OP, one trick (the one that I use) is to layer several different types of fractals and have one feed its elevation into the next. This erases the regularity of a ridge fractal completely. I have no idea what methods you are using but they look similar to what Perlin, et al. wrote about in the Texturing and Modeling book.

If anyone is curious, I could probably load up my fractal editor and show some examples of what I mean. One of the fractal types I can layer in produces those curly ridges just like in some of the pics.

1 Like
@pspeed said:

To the OP, one trick (the one that I use) is to layer several different types of fractals and have one feed its elevation into the next. This erases the regularity of a ridge fractal completely. I have no idea what methods you are using but they look similar to what Perlin, et al. wrote about in the Texturing and Modeling book.

If anyone is curious, I could probably load up my fractal editor and show some examples of what I mean. One of the fractal types I can layer in produces those curly ridges just like in some of the pics.

Yea I use 3D Perlin noise for the terrain. I actually use a similar method to compute the “desert” terrain:
[java]
float height = pow(2.0, rmf3D(p, 18, 23.0, 1.75, 0.6,0));
float desertLands1 = HMF(p * 0.85 + (0.5 * height), 1) * 0.75;
[/java]
HMF = hybrid multifractal noise and rmf3D is a variation of ridged multifractal noise (not the one described by Kenton Musgrave…I use that one for my regular mountains).

I would love to see those examples you mentioned also.

I’m not ashamed to say it. Your work gives me a boner.

@okelly4408 said: Yea I use 3D Perlin noise for the terrain. I actually use a similar method to compute the "desert" terrain: [java] float height = pow(2.0, rmf3D(p, 18, 23.0, 1.75, 0.6,0)); float desertLands1 = HMF(p * 0.85 + (0.5 * height), 1) * 0.75; [/java] HMF = hybrid multifractal noise and rmf3D is a variation of ridged multifractal noise (not the one described by Kenton Musgrave..I use that one for my regular mountains).

I would love to see those examples you mentioned also.

Ok, forgive me for the large images… map porn for the win.

In 2006 I was playing with rendering terrain and developed a Java app for combining various fractals to produce map data. It’s heavily based on the Texturing and Modeling book (Perlin, Musgrave, et al.) which to date has to be one of my favorite books.

So here is kind of what I’m talking about. This is a picture of a plain “ridge fractal” with the settings you see onthe left:

You can see that the ridges look somewhat abnormally smooth and uniform. Some of them look like smooth lines.

Upping the octave to 8 helps but things still look a bit “wrong”.

The ground more resembles something organic.

On the other hand, while Fractal Sum may look a bit more “earthy”:

Even with an increased octave, it’s kind of boring:

In Mythruna, it was very important to me to limit the amount of post processing I had to do on map data. Even a 3x3 convolution filter requires extra data to be generated and depending on the convolution kernel every tile becomes dependent on its neighbors and vice versa. It was an absolute requirement for me that I should be able to generate a tile in isolation and have it perfectly match its neighbor.

So I played a lot with stacking fractals. And since these fractal functions are typically like f(x,y,z) = h, I added the option to pass the result of the previous fractal into the next one as ‘z’… and to optionally add the layers together or just have one feed as input to the next.

If I took the ridge fractal and modified it to be a more relative fractal that I could add to the previous, something like:

And if I just add the second to the first, I get something like:

Frankly, you can hardly notice the difference at all over the plain fractal sum. But if you also use the first as input to the second, something really cool happens:

Now we’re getting somewhere.

For the record, here are the fractal implementations I’ve added to my tool… some standard, some modified a bit:
-Diamond/Squares
-Adaptive Diamond/Squares (allows preseeding a certain frequency from a previous layer)
-Midpoint displacement
-Multi-fractal
-Ridge fractal
-Heterogenous fractal
-Fractal sum
-Turbulence
-Perlin noise (straight up noise… can be layered to achieve some fractal effects manually)
-Spherical (an undulating 2D sin-wave. At a large frequency, I use this to force “islands” to appear regularly
-Erosion operator (essentially a blur filter, of sorts… convolution kernel)

Final fractal map porn, the previous combined fractal with affected+additive Turbulence on top… kind of looks lava-flowy:

4 Likes

@pspeed Your approach looks awesome.
I guess it’s more useful than the usual sample-the-neighbours fractals anyway, which tend to generate perfectly random and hence perfectly boring landscapes.

@toolforger said: @pspeed Your approach looks awesome.

Thanks!

@toolforger said: I guess it's more useful than the usual sample-the-neighbours fractals anyway, which tend to generate perfectly random and hence perfectly boring landscapes.

Neighbor sampling also has the issue that the sample direction tends to be apparent unless you take great pains to hide it. If you are sampling in four directions you will start to see crosses everywhere… if you sample in 8 then you start to see stars.

Hmm… I didn’t see crosses on Fractalus, or generally on landscapes generated with a square mesh. But you had to get the scaling factors right, which were straightforward on a square mesh and not-so-straightforward on a triangular mesh.
That’s what I thought was happening on your terrain, but if you don’t use neighbour sampling, it must be something else.
Funnily enough, 90% of the landscapes I could find with an image search had similar artifacts. Maybe everybody is now generating ridged terrain, and I’m noticing this only because I was primed with neighour-sampling fractals.

@toolforger said: Hmm... I didn't see crosses on Fractalus, or generally on landscapes generated with a square mesh. But you had to get the scaling factors right, which were straightforward on a square mesh and not-so-straightforward on a triangular mesh. That's what I thought was happening on your terrain, but if you don't use neighbour sampling, it must be something else. Funnily enough, 90% of the landscapes I could find with an image search had similar artifacts. Maybe everybody is now generating ridged terrain, and I'm noticing this only because I was primed with neighour-sampling fractals.

To which “fractalus” are you referring? The mandelbrot viewer or the fractal art web site? It will depend on the algorithm of course but I don’t have any info on that so I can’t be more specific. The software I saw is based completely on the mandelbrot or julia sets… and so isn’t even noise based, let along neighbor based. So I would need more details to comment.

If you take a look at the evolution of the raw Turbulence fractal type, you can see how these sorts of curves come about.

Here is raw Perlin noise over a particular period:

Here is just one iteration of Turbulence (not surprising, really), pretty much just thresholded perlin noise:

However… start adding some frequency iterations… 2 iterations:

4 iterations:

Even at 10 iterations, many of the most severe curves are still apparent:

And in this case, one of the down sides of regular perlin noise really starts to show. The noise period runs from 0 to 1 and all of the interesting bits are in between. Wherever there is a boundary (0, 1, 2, 3, etc.) the surface normal is always directly up (slope = 0). This starts to show up as a high frequency ‘grid’ if you are in a position to see the surface normals.

For example, here’s the regular perlin noise again but ‘shrunk’ so that we see 32x32 periods. The way I calculate my slopes for shading makes this ‘grid’ extra apparent.

Without the shading you don’t even see it:

The shading in this app uses strict left or up slopes which is why it’s really obvious. A slope that took the diagonal into account probably would hide it better… but it’s not really the point of this app. I just think this stuff is interesting.

OP, sorry to have hijacked your thread. :slight_smile:

1 Like

I meant “Rescue on Fractalus”.

@toolforger said: I meant "Rescue on Fractalus".

The 1982 game?

It’s not clear what method they were using but if it truly was “fractal” then it’s likely midpoint displacement or something similar. Either way there is not enough resolution in these games to notice the crosses.

Here is what I’m talking about. This is a midpoint displacement algorithm and it looks ok without shading:

But here is the same one with shading and you see definite artifacts:

So if Rescue on Fractalus had such artifacts then you wouldn’t have noticed them anyway. The graphics were too poor.

Something like a diamond squares algorithm shows fewer artifacts but I notice them. There is a distinct tendency to have specific angles:

Plus, these approaches require the whole tile the be generated at once and care must be taken to join the tiles. No fun really when the results aren’t even that great.

looks amazing

Yeah, it was that old game.
Point about “you wouldn’t see them without shading” noted. Though you’d see them when looking at the landscape from the side - at that time, things were mostly wireframe graphics without shaders, so all the fractal images from that time were unshaded and shown at an angle, and I didn’t notice cross artifacts.

Dunno. Maybe the cross artifacts are inevitable if using midpoint displacement. Maybe they aren’t and you can suppress them by getting the scaling factors exactly right. Maybe you need to use a Gauss distribution for the displacement. (I once tried to calculate how the random function would have to look like, but the results were nonsensical, so either the method is indeed not workable or I misunderstood something.)

@pspeed said: Ok, forgive me for the large images... map porn for the win.

In 2006 I was playing with rendering terrain and developed a Java app for combining various fractals to produce map data. It’s heavily based on the Texturing and Modeling book (Perlin, Musgrave, et al.) which to date has to be one of my favorite books.

So here is kind of what I’m talking about. This is a picture of a plain “ridge fractal” with the settings you see onthe left:

You can see that the ridges look somewhat abnormally smooth and uniform. Some of them look like smooth lines.

Upping the octave to 8 helps but things still look a bit “wrong”.

The ground more resembles something organic.

On the other hand, while Fractal Sum may look a bit more “earthy”:

Even with an increased octave, it’s kind of boring:

In Mythruna, it was very important to me to limit the amount of post processing I had to do on map data. Even a 3x3 convolution filter requires extra data to be generated and depending on the convolution kernel every tile becomes dependent on its neighbors and vice versa. It was an absolute requirement for me that I should be able to generate a tile in isolation and have it perfectly match its neighbor.

So I played a lot with stacking fractals. And since these fractal functions are typically like f(x,y,z) = h, I added the option to pass the result of the previous fractal into the next one as ‘z’… and to optionally add the layers together or just have one feed as input to the next.

If I took the ridge fractal and modified it to be a more relative fractal that I could add to the previous, something like:

And if I just add the second to the first, I get something like:

Frankly, you can hardly notice the difference at all over the plain fractal sum. But if you also use the first as input to the second, something really cool happens:

Now we’re getting somewhere.

For the record, here are the fractal implementations I’ve added to my tool… some standard, some modified a bit:
-Diamond/Squares
-Adaptive Diamond/Squares (allows preseeding a certain frequency from a previous layer)
-Midpoint displacement
-Multi-fractal
-Ridge fractal
-Heterogenous fractal
-Fractal sum
-Turbulence
-Perlin noise (straight up noise… can be layered to achieve some fractal effects manually)
-Spherical (an undulating 2D sin-wave. At a large frequency, I use this to force “islands” to appear regularly
-Erosion operator (essentially a blur filter, of sorts… convolution kernel)

Final fractal map porn, the previous combined fractal with affected+additive Turbulence on top… kind of looks lava-flowy:

Wow!! That is really cool. Very inspirational. I think I am going to need to test out that last noise combination in 3D. I started out with the diamond square algorithm but couldn’t find a good way to generate the data per-quad. Have you ever tried using Voronoi noise as a basis function? I’ve read good things about it and it seems promising. The main thing I am concerned about now is getting standard non-mountainous terrain to look good. Right now it is just this overly hilly conglomeration of hybdrid multifractal noise and some terraced ridged noise:

What does your erosion filter look like if it does not depend on neighboring chunks?