[原创]最近学习WW源码的一些认识，若有错误或不足请一定告知！3Q

          WW的纹理，DEM数据，及LOD模型

以earth为例

1．      地形数据：

默认浏览器纹理数据存放在\Cache\Earth\Images\NASA Landsat Imagery\NLT Landsat7 (Visible Color)，和高程数据一样分层存储，从服务器下载的图像为JPG格式，512*512像素，下载完毕后转换为DDS格式，DTX3压缩，所占空间会增大一倍多，但据说运行时可节约50%内存，下载的临时文件后缀为jpg.tmp,下载出错后会多一个0字节的jpg.txt文件。国界数据存放在Cache\Earth\Boundaries\Country Political Boundaries，为PNG的图片格式，更详细的地界现在只有US的：Cache\Earth\Boundaries\US State Political Boundaries，均为512*512像素的PNG图片转为DDS格式

2．      DEM数据存放在Cache\Earth\SRTM



3．      分层原理：

以地球360度经度和180度纬度为标准，第一层以36度划分，

共分为(360/36)*(180/36) = 50层，第二层以18度，第三层以9度以次类推



这也是1.4及1.4.1版本LOD模型的基础—四叉树

由于按平面展开层层划分，所以在WW里用到一个row,col的概念，类MathEngine封装了从行，列，到经，纬度值的转换，这也是WW进行纹理贴图的依据

划分后的每个方格对应一个1所说的512*512的，对应Level的纹理，有了这些信息，再加上高度值就可以实时渲染三维图像



4．如何取得高度值：
   在类TerrainAccessor和NltTerrainAccessor封装了通过行列，或者经纬度值读取Cache\Earth\SRTM对应层次BIL文件的高程信息的函数GetElevationAt等直接返回该点的高度值。



5.  LOD模型：

在1.3.5以前的版本，使用了VORM算法的LOD模型（类BinaryTriangleTree），地形数据存储在二叉树的数据结构中,对整个地形划分成块后，对每个矩形区域，都对角线连接形成两个两角形，再对每个三角形进行递归分裂，这种模型容易引起数据冗余，渲染和下载了视角以外的地形。



1．4和1.4.1 版本采用四叉树的数据结构，参照3的图解，Level 0把地球按36度划分成50个区域，第0层的每一块分裂为四个子树，这一层为Level 1层，
 

每个块都有四个子树，包括本身信息，数据定义为：
        public double West;            // 四个方向的平面笛卡尔坐标值
        public double East;
        public double North;
        public double South;
        public Angle CenterLatitude;
        public Angle CenterLongitude;
        public double LatitudeSpan;
        public double LongitudeSpan;
        public int Level;      // 层次 Level
        public int Row;            // 行，列
   public int Col;

// 子树
        protected QuadTile northWestChild;
        protected QuadTile southWestChild;
        protected QuadTile northEastChild;
   protected QuadTile southEastChild;

每一块对应当前Level的一个512*512的纹理，每一块的每条边分为40等份（这里是固定不知为何），生成41*41或43*43个顶点，再结合高度信息实时绘制。



由于分层分块的结构，对地形数据的加载和实时渲染时，只需要从服务器下载需要层次，区域的纹理图片、高程信息，还可以对有些图片进行预处理成三维果的图片直接贴图，不需要高程信息。



过渡处理：

对于Level n+1级四个子树中，若有未下载完未能处理的图片，仍然显示Level n级的效果





不知为什么图贴不上去，只好改了下，顺便问个问题，WW是不是一定要安装Direct X 的SDK，因为我一直调试程序都没安这个东西，被人鄙视了下，但调试的时候并没有什么问题