《基于高度图的地形生成技术研究毕业论文.doc》由会员分享，可在线阅读，更多相关《基于高度图的地形生成技术研究毕业论文.doc（30页珍藏版）》请在三一办公上搜索。
1、 毕业论文 论文题目：基于高度图的三维地形生成技术研究系 别：_ 计算机系_ _ _ _ _专业年级：_ _ _ _ 学 号： _ _ _ 姓 名： _ _ _ 指导教师、职称：_ 年 5 月 10 日3D Terrain Generation Based on Height MapCollege：_ Specialty and Grade： Number： Name: Advisor: Submitted time: 目录摘要1Abstract11 绪论21.1 研究的前景和意义21.2 国内外研究现状21.2 本文研究的内容32 基于OpenGLMFC的建模基础42.1 OpenGL概述4
2、2.2 OpenGL渲染管道52.2.1 显示列表52.2.2 求值器52.2.3 基于顶点的操作52.2.4 图元装配52.2.5 像素操作62.2.6 纹理装配62.2.7 光棚化62.2.8 片断操作62.3 MFC概述62.3.1 封装72.3.2 继承72.3.3 虚拟函数和动态约束82.3.4 MFC的宏观框架体系82.4 MFC编程框架82.5 基于OpenGL+MFC的三维模拟的编程环境配置113 基于高度图的地形生成153.1 由一幅高度图生成地形的原理、关键算法154 系统的设计及实现174.1 系统的实现的原理、关键技术174.2 系统中高度图的读取、纹理映射184.3
3、系统的设计184.4 实验结果（屏幕截图）205 结论与展望235.1 结论235.2 展望23致谢24参考文献25摘要本文在吸取了计算机图形学、现代数学、测绘学等众多领域大量先进理论成果的基础上，研究了地形建模的基本理论和方法基于高度图的地形生成技术.文章分析了基于高度图的均匀网格地形渲染算法，给出了具体实现并提出了有效的改进方法。该算法顶点数组来提高对均匀网格的渲染效率；在多细节层次算法中增加了地形边缘的细节层次，使地形轮廓更为清楚。指出图形生成是虚拟现实的关键问题并综述了图形生成的技术；随后回顾了地形生成及实时显示技术和方法。在此基础上通过在位图的灰度值与地形高程之间建立映射关系，快速生
4、成了三维网格地形以生成具有高度真实感的三维地形。关键词：三维地形；三维图形；地形建模；地形模型；灰度等级；三维地形模拟Abstract This thesis absorbing the computer graphics, the modern mathematics, the surveying and mapping and other advanced theory achievements, has studied the terrain modeling elementary theory and the method. This thesis analyzes the unifo
5、rmity of the height map terrain rendering algorithms, and put forward the effective improvement methods. By improving the efficiency of rendering uniform grid and adding the edge of the level of detail terrain . The terrain contours become clearer. This thesis points it out that the generation of a
6、virtual reality graphics is the key issues, and reviews the resulting graph technology and subsequently, reviews the terrain generation and real-time display technology and methods. Based on that, the thesis makes the reflect relationship between Height Chart and Terrain elevation. Eventually, a thr
7、ee-dimensional grid terrain has been mapped rapidly and then produced a highly realistic three-dimensional terrain.Key words：3D terrain ；3D graph；terain modeling；terrain model；gray level；3Dterain simulating1 绪论1.1 研究的前景和意义地形系统的研究一直的图形学的热点，虚拟地形主要几种方法分为高度图，分形等。随着计算机图形学理论以及计算机软、硬件的快速发展的发展，虚拟现实技术的发展的进步人
8、们对自然环境虚拟技术水平越来越高。三维地形图的设计与实现成为了一个重要的研究方向，在虚拟现实生活中扮演着重要的角色。在构建三维地形模型的基础上，包括地形，河流，森林，建筑，乃至经济，科学，文化，教育等方面。地形在计算机上模拟成为当今世界最热门的话题，由传统的以平面地形图为介质表示二维现实地形到用计算机完成三维地形世界的真实再现，以一种直接的、可视化的、易于理解的形式表示三维地表信息，是对客观真实的立体地形认识和表示的飞跃。根据模型的逼真度结合其他技术的应用，以地形模型研究为基础，开展地形或大型工程、著名风景名胜区的三维景观实时显示的研究，对于大型工程管理和仿真具有深远的学术意义，制作地形有好几
9、种方法来制作地形系统。每一种方法都有它的优势和弱势，用高度图来制作地形是相当简单的，而且它可以生成一些最为真实的地形结构，如果在制作地形期间，哪个细节或有大的变动，使用高度图来实现的都可以快速的完成修改。三维地形就存在我们生活范围，比如说我们的经常玩游戏。开发商为了更好的吸收玩家，开发商会不惜一切代价去开发虚拟地形，越来越细节化，游戏中的地形系统也随着时间的推移变得越来越漂亮了。实现商家的经济利益最大化。三维地形图最显著特征就是临场感，一个场景通过方向键结合其他按键来实现场景的左右旋转、放大、缩小等。实现场景漫游，可以通过设置视点以及观察方向来实现。让地形场景更接近生活，真有种身临其境的感觉。
10、再说不久前狂热3D电影阿凡达，在电影界引起热潮，创造票房的奇迹，电影中有许多地形都是虚拟的地形图。还有小区景光等等。总之虚拟地形不仅在旅游、游戏、电影这几个方面体会它的价值。它已经涉及到人们生活的方方面面，人们正在享受着它为我们带来的乐趣，并利用这个机遇为社会创造价值。1.2 国内外研究现状国外对虚拟三维的实时绘制技术研究主要集中在实时的可见性提出技术、多分辨率细节层次LOD简化技术和基于图像的绘制加速技术等。早在1976年，Clark就提出应用图形学理论管理地理信息思想。近儿年来，关于模型三维地形的研究非常火热，出现了各种算法和技术，被模拟的对象也涉及到各个方面，比如光谱数据、地形数据以及自
11、定义的几何表面等。1996年。Lindsstron等人提出了地形的连续LOD绘制算法，该算法采用了规整网格四叉树。大部被地形生成算法所引用。由于这个算法是至底向上的，所以出现大量无用的数据1。1997年Rottge等人上面的算法进进的改进。采用自顶向下的四叉树，控制相邻细节层次不超过1来进行，算法实现了用GEOMIRPHING技术的来前者的不足2。2001年HenriHaki提出了菱形地形的绘算法:CLODP 这种算法基于帧相关的ROAM算法，采用一种择的几何学结构，三角形四叉树，这种结构优于三角带，操作的次数减少许多3。2004年F.losasso和H.hoppe提出了用嵌套的规则网格来绘制
12、地形。化细节层次的方法，这个算法基于规则网格和以三角块为无素的四叉树结构。但对硬件要求较高4.2006年MALTE CLASEN和HANS提出了用球形来绘制地形。该算法基于GPU几何绘制地形算法的一个扩展，地形的位标的中点位于视点上，这样使得同中心的环的细节是随着半径的大小渐增。这不同于其它的LOD算法，这种算法在相邻区域不同的LOD之间不存在缺口问题，但是这种算法的计算量非常大6。2007ZviKongeN Jinhd Sana提出了四个直角三角形组成绘制，算法的公辩率也是四叉数据结构，但它每个块都是由四个直角三角形组成，并且每个三角形的分辩率与它相邻都是匹配的，算法均衡了CPU和GPU之间
13、的计算量，并且减少了两者之间的交互，把高程值直接当纹理来进行传输6。国内在三维地形实时绘制技术的研究方面开展了一些工作，并取得了一定的研究成果。如浙江大学CAD&CG国家重点实验室开发的桌面虚拟地形环境实时漫游系统7；浙江大学开发的虚拟地形；国防科技大学计算机学院设计并实现的高性能分布仿真系统；北京航空航天大学虚拟现实与可视化新技术研究室集成的分布式虚拟环境系统等。这些系统对虚拟环境中的一些核心技术如实时图形生成技术，模型的简化技术等领域进行了研究。但是对一些相关的基础性研究重视不够。网络三维地形中实体模型的创建和交互技术还有待进一步研究针对三维地形表面的特点，深刻剖析0penGL标准，在增强
14、地形绘制效果和提高地形绘制速度方面还有待进步深入研究地形模型的简化和多分辨率表示是三维地形模型能否实时绘制和进行动态交互的关键。它是在现有计算机硬件设备不能满足实时绘制和动态交互处理要求的前提下，从软件着手，根据人眼观察景物的特点和某个设定的精度要求，对不同地形区域采用不同的网格分辨率进行绘制，精到每个点；微机上对大规模地形实时绘制8从90年代开始，众多学者从不同的角度出发，针对地形的特点，对地形模型的简化和多分辨率表示技术进行了初步地研究9，提出了一些数据模型和算法关于这方面的研究还处在一个发展深入的阶段，针对多分辨率表示技术的要求，适合当前微机硬件环境的新模型和算法需要被提出和研究当前，真
15、实感图形实时绘制是计算机科学的研究热点1.2 本文研究的内容（1）本文综述各种三维地形生成技术的原理和实现，分析各种三维地形生成算法，着重对基于高度图的地形生成技术进行深入分析，讨论了基于高度图的地形高程生成。（2）基于高度图的地表特征的生成，深入分析基于高度图的地形生成。将三维地形逼真地绘制出来但是这是一项较为复杂的系统工程，需要借助于许多地形生成技术来实现简单的基于高度图的三维地形生成系统。（3）基于格网高程映射，对高度图进行渲染生成地形图2 基于OpenGLMFC的建模基础2.1 OpenGL概述OpenGL是个定义了一个跨编程语言、跨平台的编程接口的规格，它用于三维图象（二维的亦可）。
16、OpenGL是个专业的图形程序接口，是一个功能强大，调用方便的底层图形库。1992年7月，SGI公司发布了OpenGL的1.0版本，随后又与微软公司共同开发了Windows NT版本的OpenGL，从而使一些原来必须在高档图形工作站上运行的大型3D图形处理软件也可以在微机上运用。1995年OpenGL的1.1版本面市，该版本较1.0性能提高许多，并加入了一些新的功能。包括提高顶点位置、法线、颜色、色彩指数、纹理坐标、多边形边缘标识的传输速度，引入了新的纹理特性等等。1997年，Windows 95下3D游戏的大量涌现，游戏开发公司迫切需要一个功能强大、兼容性好的3D图形接口，而当时微软公司自己
17、的3D图形接口DirectX 3.0功能却是很糟糕。因而以制作雷神之锤等经典3D射击游戏而著名的id公司同其它一些游戏开发公司一同强烈要求微软在Windows 95中加入对OpenGL的支持。微软公司最终在Windows 95的OSR2版和后来的Windows 版本中加入了对OpenGL的支持。这样，不但许多支持OpenGL的电脑3D游戏得到广泛应用，而且许多在3D图形设计软件也可以运用支持OpenGL标准的3D加速卡，大大提高其3D图形的处理速度。2003年的7月28日，SGI和ARB公布了OpenGL 1.5。OpenGL 1.5中包括OpenGL ARB的正式扩展规格绘制语言“OpenG
18、L Shading Language”。OpenGL 1.5的新功包括：顶点Buffer Object、Shadow功能、隐蔽查询、非乘方纹理等。2004年8月，OpenGL2.0版本发布OpenGL 2.0标准的主要制订者并非原来的SGI，而是逐渐在ARB中占据主动地位的3Dlabs。opengl2.0支持OpenGL Shading Language、新的shader扩展特性以及其他多项增强特性。2008年8月初Khronos工作组在Siggraph 2008大会上宣布了OpenGL 3.0图形接口规范，GLSL1.30 shader语言和其他新增功能将再次未来开放3D接口发展指明方向。O
19、penGL 3.0 API开发代号为Longs Peak，和以往一样，OpenGL 3.0仍然作为一个开放性和跨平台的3D图形接口标准，在Shader语言盛行的今天，OGL3.0增加了新版本的shader语言：GLSL 1.30,可以充分发挥当前可编程图形硬件的潜能。同时，OGL3.0还引入了一些新的功能，例如顶点矩阵对象，全帧缓存对象功能，32bit浮点纹理和渲染缓存，基于阻塞队列的条件渲染，紧凑行半浮点顶点和像素数据，四个新压缩机制等等。2009年3月又公布了升级版新规范OpenGL 3.1，也是这套跨平台免费API有史以来的第九次更新。OpenGL 3.1将此前引入的OpenGL着色语言
20、“GLSL”从1.30版升级到了1.40版，通过改进程序增强了对最新可编程图形硬件的访问，还有更高效的顶点处理、扩展的纹理功能、更弹性的缓冲管理等等。宽泛地讲，OpenGL 3.1在3.0版的基础上对整个API模型体系进行了简化，可大幅提高软件开发效率。2009年8月Khronos小组发布了OpenGL 3.2，这是一年以来OpenGL进行的第三次重要升级。该版本仍然延续了OpenGL发展的方向让图形程序开发者能在多种操作系统和平台下更好的利用新的GPU功能。OpenGL3.2版本提升了性能表现、改进了视觉质量、提高了几何图形处理速度，而且使Direct3D程序更容易移植为OpenGL。除Op
21、enGL之外，Khronos还将其开发的其它标准进行了协调改进，以求可以在更广泛的领域提供强大的图形功能和计算生态系统，这些标准包括用于并行计算的OpenCL、用于移动3D图形开发的OpenGL ES和用于网络3D开发的WebGL。Khronos旗下的OpenGL ARB(Architecture Review Board)工作组推出了GLSL 1.5OpenGLShading Language(OpenGL着色语言)的升级版，以及在OpenGL3.2框架下推出了两个新功能，可以让开发者在开发新程序时能够在使用流水线内核特性或兼容性特性之间做出选择，其中兼容性特性会提供与旧版OpenGL之间的
22、兼容性。2.2 OpenGL渲染管道绝大多数OpenGL的实现都有一个的相类似的操作顺序，一系列处理阶段称为OpenGL渲染管道。如图1 显示了OpenGL处理数据的过程。几何数据（顶点、线、多边形）跟随着这些路径通过这些代表求值程序和每一个顶点操作的盒子，而像素数据（像素、图像、位图）的部分加工处理过程有些不同。在将最后的像素数据写到帧缓存前，两种类型的数据都要经过最后相同的步骤（光栅化和片段操作）。图1 OpenGL渲染管道下面我们更为详细的介绍OpenGL渲染管线的一些关键阶段。2.2.1 显示列表 任何数据，不管它所描述的是几何图形还是像素，都可以保存在显示列表(display lis
23、t)中，供当前或以后使用。当然，我们也可以不把数据保存在显示列表中，而是立即对数据进行处理，这种模式也称为立即模式(immediate mode)。当一个显示列表被执行时，被保存的数据就从显示列表中取出，就像在立即模式下直接由应用程序所发送的那样。2.2.2 求值器 所有的几何图元最终都要通过顶点来描述。参数化曲线和表面最初可能是通过控制点以及成为基函数(Basic function)的多项式函数进行描述的。求职器提供了一种方法。根据控制点计算表示表面的顶点。这种方法是一种多项式映射，它可以根据控制点产生表面法线、纹理坐标、颜色以及空间坐标。2.2.3 基于顶点的操作 对于顶点数据，接下来的一
24、个步骤就是基于顶点的操作，就是把顶点变换为图元。有些类型的顶点数据(例如空间坐标)是通过一个4*4的浮点矩阵进行变换的。空间坐标从3D世界的一个位置投影到屏幕上的一个位置。如果启用了高级特性，这个阶段将更为忙碌。如果使用了纹理，这个阶段还将生成并变换纹理坐标。如果启用了光照，就需要综合变换后的顶点，表面法线，光源位置，材料属性以及其他光照信息进行光照计算，产生最终的颜色值。2.2.4 图元装配 图元装配的一个主要内容就是剪裁，它的任务是消除位于半空间(half-space)之外的那部分几何图元，而这个半空间是由一个平面所定义的。点剪裁就是简单地接受或拒绝顶点，直线或多边形剪裁则可能需要添加额外
25、的顶点，具体取决于直线或多边形是如何进行剪裁的。在有些情况下，接下来需要执行一个称为透视除法(perspective division)的步骤。它使远处的物体看起来比近处的物体更小一些。接下来所进行的是视口(viewport)和深度(z坐标)操作。如果启用了剔除功能(culling)并且该图元是个多边形，那么它就有可能被剔除测试所拒绝。取决于多边形模式，多边形可能被画成点的形式或者直线的形式。这个阶段所产生的结果就是完整的几何图元，也就是根据相关的颜色，深度(有时还有纹理坐标值以及和光棚化处理有关的一些指导信息)进行了变换和剪裁的顶点。2.2.5 像素操作 在OpenGL的渲染管线中，和单路径
26、的几何数据相比，像素数据所经历的流程有所不同。首先，来自系统内存的一个数组中的像素进行解包，从某种格式(像素的原始格式可能有多种)解包为适当数量的数据成分。接着，这些数据被缩放、偏移，并根据一副像素图进行处理。处理结果先进行截取，然后或者写入到纹理内存，或者发送到光棚化阶段。如果像素数据时从帧缓冲区读取的，就对他们执行像素转换操作(缩放、偏移、映射和截取)。然后，这些结果被包装为一种适当的格式，并返回到系统内存的一个数组中。OpenGL有一种特殊的像素复制操作，可以把数据从帧缓冲区复制到帧缓冲区的其他位置或纹理内存中。这样，在数据写入到纹理内存或者写回到帧缓冲区之前，只需要进行一道像素转换就可
27、以了。2.2.6 纹理装配 OpenGL应用程序可以在几何物体上应用纹理图像，使它们看上去更为逼真。如果需要使用多幅纹理图像，把它们放在纹理对象中是一种明智的做法。这样，就可以很方便地在他们之间进行切换。有些OpenGL实现拥有一些特殊的资源，可以加速纹理的处理。这种资源可能是专用的，高性能的纹理内存。如果确实拥有这种内存，纹理对象可能会优先进行处理，以控制这种有限和宝贵的资源的使用。2.2.7 光棚化 光棚化就是把几何数据和像素数据转换为片断(fragment)的过程。每个片断方块对应用于帧缓冲区中的一个像素。把顶点连接起来形成直线或者计算填充多边形的内部像素时，需要考虑直线和多边形的点画模
28、式，直线的宽度，点的大小，着色模型以及用于支持抗锯齿处理的覆盖计算。每个片断方块都将具有各自的颜色和深度值。2.2.8 片断操作 在数据实际存储到帧缓冲区之前， 将要执行一系列的操作。这些操作可能会修改甚至丢弃这些片断。所有这些操作都可以被启用或禁用。第一个可能遇到的操作是纹理化。在纹理内存中为每个片断生成一个纹理单元(texel，也就是纹理元素)，并应用到这个片断上。接着可能进行的是雾计算，然后是剪裁测试，alpha测试，模板测试和深度缓冲区测试(深度缓冲区用于消除被隐藏的表面)。如果一个片断无法通过一个启用的测试，它的连续处理过程可能会被中断。随后，将要执行的可能是混合，抖动，逻辑操作以及
29、根据一个位掩码的屏蔽操作。最后，经过完整处理的片断就被绘制到适当的缓冲区，最终成为一个像素并到达它的最终归宿。2.3 MFC概述MFC,微软基础类(Microsoft Foundation Classes), 用于在C+环境下编写应用程序的一个框架和引擎。该类库提供一组通用的可重用的类库供开发人员使用。大部分类均从CObject 直接或间接派生，只有少部分类例外。MFC类库作为C+与Windows的接口，建立在Win32应用程序编程接口API之上，封装了大多数的API函数，主要是API中与程序结构相关的部分和最常用的部分。MFC还封装了重要的Windows扩展，如COM，ActiveX，ODB
30、C和Internet APIs，为这些难以编程实现的功能提供了简便方法。MFC中的各种类结合起来构成了一个应用程序框架，让程序员在此基础上来建立Windows下的应用程序。MFC框架定义了应用程序的轮廓，并提供了用户接口的标准实现方法，程序员所要做的就是通过预定义的接口把具体应用程序特有的东西填入这个轮廓。Visual C+提供了相应的工具来完成这个工作：AppWizard可以用来生成初步的框架文件（代码和资源等）；资源编辑器用于直观地设计用户界面；ClassWizard用来协助添加代码到框架文件；最后进行编译，则通过类库实现了应用程序特定的逻辑。在MFC编程中，入口函数WinMain()被封
31、装在MFC的应用程序框架内，已经不用也不可以再定义为另一个WinMain()函数。MFC编程最好的办法是使用MFC的应用程序向导工具AppWizard。AppWizard为程序员提供了一种快捷方便的工具来定制基于MFC的应用程序框架，程序员只需以此为基础，添加与修改程序代码来实现所需功能。MFC是一个编程框架，MFC中的各种类结合起来构成了一个应用程序框架，它的目的就是让程序员在此基础上来建立Windows下的应用程序，这是一种相对SDK来说更为简单的方法。因为总体上，MFC框架定义了应用程序的轮廓，并提供了用户接口的标准实现方法，程序员所要做的就是通过预定义的接口把具体应用程序特有的东西填入
32、这个轮廓。Microsoft Visual C+提供了相应的工具来完成这个工作：AppWizard可以用来生成初步的框架文件（代码和资源等）；资源编辑器用于帮助直观地设计用户接口；ClassWizard用来协助添加代码到框架文件；最后，编译，则通过类库实现了应用程序特定的逻辑。2.3.1 封装 构成MFC框架的是MFC类库。MFC类库是C+类库。这些类或者封装了Win32应用程序编程接口，或者封装了应用程序的概念，或者封装了OLE特性，或者封装了ODBC和DAO数据访问的功能，等等，分述如下。（1）对Win32应用程序编程接口的封装用一个C+ Object来包装一个Windows Object
33、。例如：class CWnd是一个C+ window object，它把Windows window(HWND)和Windows window有关的API函数封装在C+ window object的成员函数内，后者的成员变量m_hWnd就是前者的窗口句柄。（2）对应用程序概念的封装使用SDK编写Windows应用程序时，总要定义窗口过程，登记Windows Class，创建窗口，等等。MFC把许多类似的处理封装起来，替程序员完成这些工作。另外，MFC提出了以文档-视图为中心的编程模式，MFC类库封装了对它的支持。文档是用户操作的数据对象，视图是数据操作的窗口，用户通过它处理、查看数据。（3）对
34、COM/OLE特性的封装OLE建立在COM模型之上，由于支持OLE的应用程序必须实现一系列的接口（Interface），因而相当繁琐。MFC的OLE类封装了OLE API大量的复杂工作，这些类提供了实现OLE的更高级接口。（4）对ODBC功能的封装以少量的能提供与ODBC之间更高级接口的C+类，封装了ODBC API的大量的复杂的工作，提供了一种数据库编程模式。2.3.2 继承 首先，MFC抽象出众多类的共同特性，设计出一些基类作为实现其他类的基础。这些类中，最重要的类是CObject和CCmdTarget。CObject是MFC的根类，绝大多数MFC类是其派生的，包括CCmdTarget。C
35、Object 实现了一些重要的特性，包括动态类信息、动态创建、对象序列化、对程序调试的支持，等等。所有从CObject派生的类都将具备或者可以具备CObject所拥有的特性。CCmdTarget通过封装一些属性和方法，提供了消息处理的架构。MFC中，任何可以处理消息的类都从CCmdTarget派生。针对每种不同的对象，MFC都设计了一组类对这些对象进行封装，每一组类都有一个基类，从基类派生出众多更具体的类。这些对象包括以下种类：窗口对象，基类是CWnd,派生了CView类；应用程序对象，基类是CwinThread；文档对象，基类是Cdocument，等等。程序员将结合自己的实际，从适当的MFC
36、类中派生出自己的类，实现特定的功能，达到自己的编程目的。2.3.3 虚拟函数和动态约束 MFC以“C+”为基础，自然支持虚拟函数和动态约束。但是作为一个编程框架，有一个问题必须解决：如果仅仅通过虚拟函数来支持动态约束，必然导致虚拟函数表过于臃肿，消耗内存，效率低下。例如，CWnd封装 Windows窗口对象时，每一条Windows消息对应一个成员函数，这些成员函数为派生类所继承。如果这些函数都设计成虚拟函数，由于数量太多，实现起来不现实。于是，MFC建立了消息映射机制，以一种富有效率、便于使用的手段解决消息处理函数的动态约束问题。这样，通过虚拟函数和消息映射，MFC类提供了丰富的编程接口。程序
37、员继承基类的同时，把自己实现的虚拟函数和消息处理函数嵌入MFC的编程框架。MFC编程框架将在适当的时候、适当的地方来调用程序的代码。本书将充分的展示MFC调用虚拟函数和消息处理函数的内幕，让读者对MFC的编程接口有清晰的理解。2.3.4 MFC的宏观框架体系 如前所述，MFC实现了对应用程序概念的封装，把类、类的继承、动态约束、类的关系和相互作用等封装起来。这样封装的结果对程序员来说，是一套开发模板（或者说模式）。针对不同的应用和目的，程序员采用不同的模板。例如，SDI应用程序的模板，MDI应用程序的模板，规则DLL应用程序的模板，扩展DLL应用程序的模板，OLE/ACTIVEX应用程序的模板
38、，等等。这些模板都采用了以文档-视为中心的思想，每一个模板都包含一组特定的类。典型的MDI应用程序的构成将在下一节具体讨论。为了支持对应用程序概念的封装，MFC内部必须作大量的工作。例如，为了实现消息映射机制，MFC编程框架必须要保证首先得到消息，然后按既定的方法进行处理。又如，为了实现对DLL编程的支持和多线程编程的支持，MFC内部使用了特别的处理方法，使用模块状态、线程状态等来管理一些重要信息。虽然，这些内部处理对程序员来说是透明的，但是，懂得和理解MFC内部机制有助于写出功能灵活而强大的程序。总之，MFC封装了Win32 API，OLE API，ODBC API等底层函数的功能，并提供更
39、高一层的接口，简化了Windows编程。同时，MFC支持对底层API的直接调用。MFC提供了一个Windows应用程序开发模式，对程序的控制主要是由MFC框架完成的，而且MFC也完成了大部分的功能，预定义或实现了许多事件和消息处理，等等。框架或者由其本身处理事件，不依赖程序员的代码；或者调用程序员的代码来处理应用程序特定的事件。MFC是C+类库，程序员就是通过使用、继承和扩展适当的类来实现特定的目的。例如，继承时，应用程序特定的事件由程序员的派生类来处理，不感兴趣的由基类处理。实现这种功能的基础是C+对继承的支持，对虚拟函数的支持，以及MFC实现的消息映射机制。2.4 MFC编程框架用AppW
40、izard产生一个MDI工程t（无OLE等支持），AppWizard创建了一系列文件，构成了一个应用程序框架。这些文件分四类：头文件（.h），实现文件(.cpp)，资源文件(.rc)，模块定义文件(.def)，等。 （a）构成应用程序对象下图解释了该应用程序的结构，箭头表示信息流向。 图1 MDI应用程序的构成从CWinApp、CDocument、CView、CMDIFrameWnd、CMDIChildWnd类对应地派生出CTApp、CTDoc、CTView、CMainFrame、CChildFrame五个类，这五个类的实例分别是应用程序对象、文档对象、视对象、主框架窗口对象和文档边框窗口对象
41、。主框架窗口包含了视窗口、工具条和状态栏。对这些类或者对象解释如下。 （1）应用程序 应用程序类派生于CWinApp。基于框架的应用程序必须有且只有一个应用程序对象，它负责应用程序的初始化、运行和结束。 （2）边框窗口 如果是SDI应用程序，从CFrameWnd类派生边框窗口类，边框窗口的客户子窗口(MDIClient)直接包含视窗口；如果是MDI应用程序，从CMDIFrameWnd类派生边框窗口类，边框窗口的客户子窗口(MDIClient)直接包含文档边框窗口。 如果要支持工具条、状态栏，则派生的边框窗口类还要添加CToolBar和CStatusBar类型的成员变量，以及在一个OnCreat
42、e消息处理函数中初始化这两个控制窗口。 边框窗口用来管理文档边框窗口、视窗口、工具条、菜单、加速键等，协调半模式状态（如上下文的帮助(SHIFT+F1模式)和打印预览）。 （3）文档边框窗口 文档边框窗口类从CMDIChildWnd类派生，MDI应用程序使用文档边框窗口来包含视窗口。 （4）文档 文档类从CDocument类派生，用来管理数据，数据的变化、存取都是通过文档实现的。视窗口通过文档对象来访问和更新数据。 （5）视 视类从CView或它的派生类派生。视和文档联系在一起，在文档和用户之间起中介作用，即视在屏幕上显示文档的内容，并把用户输入转换成对文档的操作。 （6）文档模板 （a）文档
43、模板类一般不需要派生。MDI应用程序使用多文档模板类CMultiDocTemplate；SDI应用程序使用单文档模板类CSingleDocTemplate。 应用程序通过文档模板类对象来管理上述对象（应用程序对象、文档对象、主边框窗口对象、文档边框窗口对象、视对象）的创建。 （b）构成应用程序的对象之间的关系图3 应用程序的对象之间的关系 用图的形式可直观地表示所涉及的MFC类的继承或者派生关系，如图3所示意。 图所示的类都是从CObject类派生出来的；所有处理消息的类都是从CCmdTarget类派生的。如果是多文档应用程序，文档模板使用CMultiDocTemplae，主框架窗口从CMdi
44、FarmeWnd派生，它包含工具条、状态栏和文档框架窗口。文档框架窗口从CMdiChildWnd派生，文档框架窗口包含视，视从CView或其派生类派生。（c） 构成应用程序的文件通过上述分析，可知AppWizard产生的MDI框架程序的内容，所定义和实现的类。下面，从文件的角度来考察AppWizard生成了哪些源码文件，这些文件的作用是什么。表1列出了AppWizard所生成的头文件，表2列出了了AppWizard所生成的实现文件及其对头文件的包含关系。 表1 AppWizard所生成的头文件表2 AppWizard所生成的实现文件 从表2中的包含关系一栏可以看出： CTApp 的实现用到所有
45、的用户定义对象，包含了他们的定义；CView 的实现用到CTdoc；其他对象的实现只涉及自己的定义； 当然，如果增加其他操作，引用其他对象，则要包含相应的类的定义文件。2.5 基于OpenGL+MFC的三维模拟的编程环境配置下面介绍在VC 环境中建立基于 OpenGL 标准的应用程序框架的具体方法与步骤(1) 创建MFC项目文件：选择File/New 菜单选项，建立一个名为 MyTest 的单文档 (SDI) 应用程序 (2) 配置OpenGL编程环境：即添加OpenGL图形开发接口库文件。选择Project/Setting 菜单选项，在 Link 栏的 Lib 输入域中添加 openg132
46、.lib 、 glu32.lib ，若需使用 OpenGL 的辅助库函数，则还需添加 glaux.lib 。 (3) 为CMyTestView 类添加成员函数 void Init() ，用于初始化，代码如下：HGLRC hrc; m_pDC = new CClientDC(this);/ OpenGL初始化工作：获取dcif (!bSetupPixelFormat() /设置像素格式hrc = wglCreateContext(m_pDC-GetSafeHdc();/创建RCglViewport(0, 0, w, h); gluPerspective(45,ratio,1,1000);/设置OpenGL视口变换(4) 为CMyTestView 类添加成员函数 BOOL bSetupPixelFormat(void) ， 用于与OpenGL 相关的设置 /*定 义 像 素 存 储 格 式 */ BOOL CMyTerrain1View:SetupPixelFormat()PIXELFORMATDESCRIPTOR pfd = sizeof(PIXELFORMATDESCRIPTOR), / pfd结构的大小 1, / 版本号 PFD_DRAW_TO_WINDOW | / 支持在窗口中绘图 PFD_SUPPORT_OPENGL | / 支持 OpenGL PFD
