Fractal terrain with geometry-texture cutoff

Started by
5 comments, last by Krohm 12 years ago
I have a terrain renderer up and running with geomipmapping and all and one can edit it by hand and load heightmaps. Although this freedom allows you in principle to make any terrain you like, seeing some images of fractal terrain generation have convinced me that maybe it would be far better to, at least for a starting point, use some procedural heightmap generation.

To me the square-diamond and Fourier transform methods sound usable for a starter. I started wondering that if a terrain will contain a lot of high frequency detail, then would it be practical to use a combination of geometry representation and normal maps? So the idea would be to define a threshold wavelength, so that this wavelength is barely representable with given terrain mesh. Then a heightmap would be generated by using some fractal algorithm. This heightmap is then Fourier transformed and all wavelengths below the threshold would be inverse transformed to be used for the normal map and the longer wavelengths would be inverse transformed to the heightmap that would be used for the mesh. Has anyone tried this or something similar? If the Fourier transform method is used to create the fractal, then this would be most natural.
Advertisement
The problem with high frequency data is that it needs to be sampled at very small intervals, otherwise you get the shard effect which looks like triangles randomly coming out of the ground because this point happened to have a high amplitude while another near had a low one. Even normal mapping doesn't help in this situation. And of course, more sample points means more triangles which means higher load on whatever hardware you are using. You need to limit your frequency band to accomodate your sampling rate with respect to area.

What you suggest should in theory work (using low frequency for the geometry and high frequency for normal map synthesis) but I am not sure how nice the normal maps would look. Another issue is that the cutoff may in fact be quite noticeable because of the linear interpolation being done on the geometry level. And Fourier Transforms are not exactly cheap either (even on the GPU), so it may not be worth the performance hit. But it would be interesting to see nonetheless.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”


What you suggest should in theory work (using low frequency for the geometry and high frequency for normal map synthesis) but I am not sure how nice the normal maps would look. Another issue is that the cutoff may in fact be quite noticeable because of the linear interpolation being done on the geometry level. And Fourier Transforms are not exactly cheap either (even on the GPU), so it may not be worth the performance hit. But it would be interested to see nonetheless.


Yes I'm a bit worried also about what artifacts the filter will introduce. But I'm not particularly interested in doing the terrain generation in realtime, but as a pre-process. The normal map and heightmap would be static during their use. To get most out of the normal map, probably even one huge texture won't cut it for the whole terrain (say that I'm interested in terrains of around (10km)^2).
Ok maybe this filtering is not very useful as storing unique high frequency data to normal maps would lead to high storage requirements anyway.

How is fractal terrain texturing usually done in real time graphics? I understand that one uses a few tileable textures and their weight is determined by slope, elevation and so on, which can be obtained in shaders from the heightmap. Then they modulate this data with some fractal noise. Is this correct? Is this fractal usually some precomputed texture or can you actually produce some true fractals in the shaders to "unlimited" fidelity, so that they are appropriate for this terrain texture modulation?
It depends. For 3D volumetric terrain you usually have no choice but to use triplanar texturing (3 textures weighted dependng on the dot product of the normal with all three coordinate axes) since there is no analytical function that will map a 2D texture to an arbitrary 3D topological surface without stretching or shearing.

If you are using a heightmap it is simpler, and usually a couple of textures are being mapped to the geometry and are sometimes combined (by linearly interpolating them at each pixel using fractal noise) to reduce repetition. It can also depend on the surface's slope (e.g. add more of the "rock" texture on very steep slopes, since it's probably a cliff).

I would guess games use precomputed fractals (since they can't afford that much time to the terrain) if any to blend the terrain textures together, but I suppose with the increase in computing power shader-based fractal generation is becoming a possibility.

Note that "infinite fidelity" is not possible. The fractal noise is obtained by summing up various amplitudes and frequencies of random noise, which means that the fractal noise becomes more and more detailed as you increase the number of iterations. So to get a really clean fractal you need to iterate several times which slows down the shader. But in general if you are going to use it to blend textures together only a couple of iterations are enough as the player is not usually concentrating on this particular feature (and it looks good from far away, of course). And there's still the floating-point limit.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”


Note that "infinite fidelity" is not possible. The fractal noise is obtained by summing up various amplitudes and frequencies of random noise, which means that the fractal noise becomes more and more detailed as you increase the number of iterations. So to get a really clean fractal you need to iterate several times which slows down the shader. But in general if you are going to use it to blend textures together only a couple of iterations are enough as the player is not usually concentrating on this particular feature (and it looks good from far away, of course). And there's still the floating-point limit.


By "infinite" I was more thinking about producing self-similar pattern at arbitrary scale. So if camera moves closer to a cliff, the texturing pattern would produce patterns in smaller scale, neglecting the larger scale that would not be observable anymore. I'm not sure how all fractals in general work, but I was thinking that maybe this is possible. So basically like zooming into the Koch snowflake. Only a portion of the flake is visible at a particular scale. In the case of noise, maybe the low frequency channels could be moved to be used for a higher frequency in an ever-repeating fashion, as the scale gets smaller.

I have a terrain renderer up and running with geomipmapping and all and one can edit it by hand and load heightmaps. Although this freedom allows you in principle to make any terrain you like, seeing some images of fractal terrain generation have convinced me that maybe it would be far better to, at least for a starting point, use some procedural heightmap generation.
I'm not on your line of thinking. Complete procedural generation for terrains is useful, but most of the time it's just heightmaps. What problem are you exactly going to resolve?

Then a heightmap would be generated by using some fractal algorithm. This heightmap is then Fourier transformed and all wavelengths below the threshold would be inverse transformed to be used for the normal map and the longer wavelengths would be inverse transformed to the heightmap that would be used for the mesh. Has anyone tried this or something similar?
No, and I don't understand the whole point. I would just run the fractal twice, at mesh resolution and normalmap resolution. The mesh would effectively be a low-pass and the difference between the interpolated lowpass'd and the hi-res would be the higher frequency octaves. FFT would give you all the octaves explicitly but nobody needs than. We care about the final sum only, and that's what I'd get out of this method.

Previously "Krohm"

This topic is closed to new replies.

Advertisement