assaf raman
07-05-2006 10:36:41
Have a look, I found this article that talk about technologies that are in use in MSFS.
http://www.fsinsider.com/articles/Global_Terrain_Technology.htm
It would be nice if PLSM would have support for "The Earth’s curvature".
Also there is a reference to the way they render linear vector features.
Lastly they talk about floating point issues for massive terrain.
http://www.fsinsider.com/articles/Global_Terrain_Technology.htm
It would be nice if PLSM would have support for "The Earth’s curvature".
The RQT algorithm, as published, is really intended for “flat” Earth terrain where the sea level elevation reference is assumed to be an infinite plane. Since Flight Simulator models the Earth’s curvature, we had to modify the algorithm a bit. The main problem is that the unmodified RQT tends to eliminate nearly all the mesh vertices over large open expanses of ocean which it interprets as being completely flat. The solution is to increase the error metric for each point in the mesh by the height of the Earth’s curvature above the line connecting the point’s opposite neighbors. The result is an increase in the error metric roughly proportional to the distance to its neighbors. The larger the error metric, the less likely a point will be eliminated from the triangulation. This helps preserve the Earth’s curvature in large areas with the same elevation.
Also there is a reference to the way they render linear vector features.
At this point, we render a variety of linear vector features representing things like roads, streams, and shorelines. All are drawn into the target image as wide textured lines. Any roads with street lights get rendered in two passes, diffuse and emissive. The shorelines, usually just rendered into the diffuse target, help soften the edge between the land and water that was created when the water bodies were rasterized into the class map.
Lastly they talk about floating point issues for massive terrain.
The equations must be evaluated using 64-bit floating point to prevent a loss of precision. The seven significant digits of 32-bit floats aren’t enough to represent a point with better than sub meter accuracy. Since the rendering pipeline (Direct3D in this case) uses 32-bit floats, the final coordinates used for rendering must be converted to 32-bit offsets from a 64-bit local origin no more than several thousand meters away (see Figure 7). It would be simpler if each cell had its own local origin and world-to-camera matrix, but then small cracks would be visible between cells due to floating-point imprecision. Therefore, all the cells must share the same local origin and matrix.
As the viewpoint moves through the world, the local origin must be periodically updated to keep it within a few kilometers of the viewpoint. Otherwise, a loss of precision results making the terrain vertices appear to wiggle around as the viewpoint moves, an interesting but obviously undesirable outcome. Whenever we update the local origin, all the vertex buffers in every cell of the quad tree must be recomputed relative to the new origin. As this can take several frames, the new vertex data is double buffered and then made active only when all are ready to avoid visible cracks.