Outerra Engine > Technology

Planetary Engine in detail

(1/2) > >>

Aleksandar Dimitrijevic:
Hello Brano, and thank you for the invitation for this forum!

I'm also involved in the development of a large terrain rendering algorithm, so I hope we have a lot of topics to discuss about. :)

First of all, I have to congratulate you on your effort to build extraordinary engine!

Let's continue the discussion from the Intro page...

--- Quote from: Brano Kemen ---Yes, using a geocentric coordinate system for the planet directly would allow only for limited precision, and thus it can be used only up to a certain level of detail (i.e. for some maximum distance from the surface). So what I do is that the geometry for the more detailed terrain tiles is generated in its "local space", what is a coordinate system centered in the middle of the terrain tile that starts to use it. All subsequent subdivisions of this tile use the same coordinate system.
Finally, for the rendering of these tiles the camera is expressed in the local space too. This way you get rid of large static numbers in coordinates that ruin the precision.
--- End quote ---
Yes, that is exactly what must be done, but there is a problem when switching from one "local" tile to the other.

Many applications I am involved now does not require planet-sized terrain, so I've discarded all calculation involving Earth's diameter on certain geographic latitude and geoid's correction. But rendering the whole Earth will always be a hot topic. ;)

During the reading your posts, I have found some interesting ideas that are just mentioned and not explained, and I'm very curious if you can give just a bit of explanation on them.

One of them is using wavelet compressed terrain data. Which algorithm are you using? Ecw, MrSID, JPEG200, or some custom built? Five years ago I had carried out some experiments with ECW compression and found out that it cannot be used, because of very high level of degradation. That degradation is suitable for the image, because our eye cannot find the distinction in the variations of colors, but using it on the terrain heights is not acceptable.  Lossless compressions can be used, but the compression-rate is moderate or poor (except on the large water surfaces with zero-elevation).

The idea of using torrent protocol for the data retrieval is excellent!

Can you give us a clue on what algorithm is based Outerra for managing terrain LOD? Quadtrees, Octrees, Clipmaps, Ray casting or something quite different?

cameni:
Welcome, and thanks for the kind words.

There is no problem with switching between separate local spaces that I'm aware of, can you explain what you mean?

We are using custom wavelet compression, that does not smoothen the terrain when producing coarser levels. You are right, what is good for images is not at all good for the height maps. Initially we used Haar wavelet but due to the smoothing it was unusable. Currently we are using one (don't know if it's got a name) that reduces a (2n+1)*(2n+1) map to a (n+1)*(n+1) one by picking every other row and column, and encoding the remaining points as differences to the interpolated values. It's lossless compression, and the final dataset for Earth with resolution ~76m is somewhere around 13 gigs.

But just a small part of it is needed, I think it was 20Mb when landing perpendicularly on Earth surface, and more data was needed only after moving several kilometers away. Also, thanks to the wavelet and separation of LOD layers, less data is needed when flying in higher altitudes. So it can be all downloaded progressively.

Terrain LOD is managed using quad-trees, with error metric that considers the amount of texture stretching on terrain tile to decide when to subdivide.

Aleksandar Dimitrijevic:

--- Quote from: cameni ---There is no problem with switching between separate local spaces that I'm aware of, can you explain what you mean?
--- End quote ---
The problem is in the fact that I'm trying to minimize terrain reorganization and keep all coordinates of the vertices in the block. Moving from one coordinate system to the other requires blocks reorganization, which is an expensive operation for me. I didn't think much about that, but I'll post my solution when I consider all possibilities and carry out some experiments and measure the speed of execution.

--- Quote from: cameni ---Initially we used Haar wavelet but due to the smoothing it was unusable. Currently we are using one (don't know if it's got a name) that reduces a (2n+1)*(2n+1) map to a (n+1)*(n+1) one by picking every other row and column, and encoding the remaining points as differences to the interpolated values.
--- End quote ---

That is exactly what I'm doing, but currently do not use compression. Textures are much greater than DEM and so far I didn't need to compress it, but I will for sure. Thank you for the suggestion!

Did you publish any paper on this topic? I would like to try floating point Z-buffer extensions and logarithmic Z-buffer in my algorithm (although currently I don't have problems with z-fighting because of dynamically changing near and far clipping planes), and it will be useful to have a reference.

cameni:

--- Quote from: Aleksandar ---The problem is in the fact that I'm trying to minimize terrain reorganization and keep all coordinates of the vertices in the block. Moving from one coordinate system to the other requires blocks reorganization, which is an expensive operation for me. I didn't think much about that, but I'll post my solution when I consider all possibilities and carry out some experiments and measure the speed of execution.
--- End quote ---
What method do you use for LOD? Because it sounds you re doing something very differently. With the quadtrees I'm simply generating tiles up to a specific quadtree level in the global (geocentric) coordinate system, and tiles from that level and deeper are generated in their local coordinate spaces. Once the VBOs are generated, they are never reorganized or anything, just rendered with appropriately shifted camera.

--- Quote ---Did you publish any paper on this topic? I would like to try floating point Z-buffer extensions and logarithmic Z-buffer in my algorithm (although currently I don't have problems with z-fighting because of dynamically changing near and far clipping planes), and it will be useful to have a reference.
--- End quote ---
No I didn't write any paper on it, I'm not skilled in writing academic papers (I never tried ;)).
But of course I'll gladly help you if you find any problems with it or if there's something unclear.

Aleksandar Dimitrijevic:

--- Quote from: cameni ---What method do you use for LOD? Because it sounds you re doing something very differently.
--- End quote ---
Yes, indeed. My algorithm is similar to clipmaps, but the whole terrain is organized into blocks of equal spatial size, but the LOD depends on the distance from the viewer (using nested rings). Each block is a mini-world for itself and does not change its structure as long as it says in the bounding box of certain LOD level (i.e. ring). In 2006. I published two papers on this topic, but then the algorithm was at its beginning with many things unsolved. In that time I have to develop an algorithm that uses fixed functionality (because of equipment it had to be executed on) and to achieve highest possible frame rate with minimal CPU utilization. Now the time has come to change it a bit. :)

--- Quote ---No I didn't write any paper on it, I'm not skilled in writing academic papers (I never tried ;)).
--- End quote ---
But you should try! ;)
Practical approach, skills and ideas you have should be published as an academic paper.