I know when rendering terrain, terrain is usually equal-sized tiled, and a vbo with the same size is prepared. the tiles contain height values only. at runtime, this vbo is rendered and a vertex shader is used to do vertex texture fetch from such as tile A, and tile A is rendered. and then B C D…
but when it comes to real geographic data, it is not the case any more. because the earth on which we stand is an ellipsoid. terrain data are given as elevation from the ellipsoid, such as the SRTM data . tile A and tile B at ellipsoid do not have the same shape any more, and naturally a vbo can represent all tiles do not exist. the scheme using VTF does not work now.
so what is the solution in real GIS system? make the tiles contain all the 3 coordinates but not only the hight value?
That is one option, but it is far from the only approach.
…but when it comes to real geographic data, it is not the case any more. because the earth on which we stand is an ellipsoid. terrain data are given as elevation from the ellipsoid, such as the SRTM data . tile A and tile B at ellipsoid do not have the same shape any more
While orthorectified regular grid height data as elevation from the ellipsoid may be the format that it comes in from NIMA/NGA/NASA/wherever, that doesn’t mean it needs to be what you page off disk and shovel onto the GPU. This can be a very, very inefficient form to render terrain with.
…and naturally a vbo can represent all tiles do not exist. the scheme using VTF does not work now.
so what is the solution in real GIS system? make the tiles contain all the 3 coordinates but not only the hight value?
I didn’t really understand that at all (even given that VTF=vertex texture fetch). Could you clarify?
Tessellation problem you have noticed is just a small fraction of problems you will encounter while developing a “real” terrain rendering engine. I hope previous references will help you on your “voyage”.
… But don’t hesitate to ask for further explanation …
What I want to do is to repeat the tile scheme mensioned above over the suface of the earth ellipsoid. That is, Draw a Spherical rectangular that fit right on the ellipsoid suface, and offset the vertices along the ellipsoid normals the according DEM, then move the rectangular to other part of the ellipsoid , the shape of the spherical rectangular should be changed a little to fit local curvature ,until the entire terrain is rendered.
Since you told me this is very inefficient, it does not make sence any more.
I was told that usually earth ellipsoid is not taken into accout when rendering terrain in a small extent. When terrain size gets really large, another commonly used approximation is just put the four corners of one tile on the ellipsoid, and the other vertices are got by trilinear interpolation. Is this scheme popular in most GIS systems? Does any other method exist?
@Aleksandar :
The resources you directed is very useful. And I have read many papers on Virtual Terrain Project. But most papers just discuss LOD algoritms, where the terrain is rendered in flat mode. Still I don not know how to apply these algoritms on spherical terrains.
The book, 3D Engine Design for Virtual Globes, must be the book I need, but it seems that very diffidult to get one in a short time since i live in china.
So, May i ask more resouces about how to render a terrain over the ellipsoid?
I see. Essentially you want to tile the earth with roughly-rectangular tiles. You can certainly do this. In fact, as the scale decreases (more is visible) you could have a multilevel tiling scheme (e.g. nested tiling scheme) so that your roughly-rectangular tiles get larger and larger. And what you page from disk can be based on this tiling grid. This is all usual and a very reasonable approach.
Since you told me this is very inefficient, it does not make sence any more.
My comment was directed not at tiling the world and paging (loading) on tile boundaries, but rather uploading (for each tile) a regular grid to the GPU and using VTF to subsample this grid. Some things to think about there: what percentage of what you upload to the GPU are you actually using (max and min; anything you’re not using is wasted space/bandwidth/time), random GPU memory reads (access performance) just to figure out where the verts are supposed to be, in flat areas you actually need a low density tri mesh whereas in areas of high curvature you need a higher density tri mesh (if you render high enough density for the high curvature areas even in low curvature areas you waste GPU vertex perf), similar problem applies to near and far regions in your frustum (need higher density near and lower density far, otherwise you waste perf).
View dependent LOD is one approach that folks have applied to this over the years, where you dynamically determine the trimesh you want to render based on some view-space error metric(s). Can be applied to regular grids, where you’re dynamically, incrementally, computing the trimesh and stitching tri meshes at run-time, carefully avoiding T-junctions so that you don’t get cracks in your terrain grid. Can be done, but eats run-time perf doing it. Techniques range in all granularities, from stitching individual triangles to stitching whole blocks of the terrain grid as a whole.
Another approach to look at is precomputed TIN methods (triangulated irregular meshes) built from those regular grid terrains as a pre-process. Con is the preprocessing time required for this. Pro is that you don’t spend run-time cycles trying to compute this grid, what mesh you do end up sending to the GPU is 100% used, and it is streamed very efficiently to the GPU (no random reads just to figure out what the vertex positions are). View dependent LOD can be applied to this too, though here you use it to decide which LOD mesh to render, not how to stitch together tris to build a mesh.
So it’s really just a matter of what your requirements are. If your needs are modest, could be that pure regular grid rendering with a few tricks is all you really need.
Not necessarily. Many of them, especially ray-casting does not relay on the particular grid. Maybe this would be more interesting for you: Terrain LOD on Spherical Grids
Generally, I would recommend you the following (main) approaches:
Generate each tile as a full 3D mesh according to its position on the globe and terrain heights, or make only grid on the CPU and update heights from the texture in the vertex/tessellation shader. Block/grid re-usage is possible only on the same latitude. Disadvantage: hight bandwidth utilization since update requires transferring a lot of data and the tile generation is on the CPU mostly (or exclusively).
Generate tiles on the fly in the vertex/tessellation shader. This is my favorite technique. The grid for each tile is generated in shaders. Update is limited only to a texture/hight update. Disadvantage: More complicated and pron to precision errors.
Using ray-casting for rendering. This is a very popular method nowadays. Removes primitive assembly and rasterization bottleneck. The whole process is moved to the last programmable stage - fragment shader. Disadvantage: Complicated and slow if not properly optimized.
In all cases, clipmaps are probably the best way to organize and update data. But, for the whole planet, it should be divided into several separate parts. Also consider rendering a spherical world instead of ellipsoidal. The math will be much easier and you won’t see any difference from the surface.
hi，Aleksandar. I have not read the papers you directed yet. I will read them later.
I once implemented one ray-casting method from a paper "gpu ray-casting for scalable terrain rendering"http://wwwcg.in.tum.de/en/research/research/publications/2009/gpu-ray-casting-for-scalable-terrain-rendering.html.
It was slow so has been abandoned. It has about 200 lines of GLSL, not too much, but the lack of proper GLSL debugger really made me suffer. Besides performance, another issue was that the image quality was poor, you need additional codes to handle aliasing.
I think i will be working on the second kind of methods.
Thanks very much for your help.
