土木在线论坛 \ BIM技术 \ 道桥BIM应用 \ 铁路桥梁BIM程序的设计与实现

铁路桥梁BIM程序的设计与实现

发布于：2020-11-13 14:29:13 来自：BIM技术/道桥BIM应用 [复制转发]

商业化的设计平台虽好，但自主研发的平台有不可替代的优点

商业化平台技术成熟、模型渲染美观，特别是在空间几何计算方面的优势非常突出，但同时也存在一些问题：（1）专业性设计功能完全需要二次开发；（2）不掌握核心代码，无法修改其核心用户界面（UI）以及固有的操作模式，为操作带来不便；（3）纯英文的开发接口程序库，为二次开发带来极大困难。

因此，如果仅仅是进行三维仿真建模的话尚且可行，但如果要利用其开发长大桥梁的正向设计功能，将无法绕开上述问题，另外，商业化平台的前期购买以及后期升级维护成本较高。

相反，如果自主开发桥梁BIM设计程序，因为涉及到空间几何计算、坐标系统、划网建模、3D 渲染、长大场景调度等前沿性技术，在开发难度、开发成本、开发周期方面都有较大风险和阻力。但优势在于掌握核心代码，其设计模式及显示界面均可根据使用者需求量身定制，并且程序升级改造灵活、维护成本低。

本文从OpenGL图形渲染的底层功能着手，自主研发BIM建模平台，介绍一款兼具二维交互设计和三维显示功能的铁路桥梁BIM程序。并从铁路桥梁设计的专业角度出发，在程序的开发思路、设计模式比选，以及在视图显示的关键性技术方面做出探索。

程序设计模式

三维桥梁设计程序的特点

（1）在桥梁设计计算方面，需要结合梁缝计算、结构计算等自身的专业性软件，进行协同设计。

（2）在图形类型方面，桥梁工程相对于路基、站场等专业，以及对空间曲面建模方面有更多需求。

（3）在建模方式方面，铁路桥涵设计除了需要建立标准图库来满足标准化结构部件建模以外，桥址范围内的边坡防护、涵洞顺沟等，还需要根据设计参数及三维地形，进行自动化的自适应性建模。

（4）特大型铁路桥梁在国内高速铁路桥梁设计中非常普及，单座桥梁长度突破几百公里以上的情况已形成常态，而桥梁孔跨布置是由精密计算而来，对BIM中任意一处孔跨的更改，都将牵动整座桥数百公里梁跨的重新设计和图形重构。因此，BIM设计程序不仅要求高性能的计算机硬件，对程序数据结构的合理性及算法的高效性也都有较高要求。

二维、三维视图并存的设计模式

目前，国内铁路项目采用的主要BIM设计平台，如：revit、bently、达索等，都是在纯三维模式下开展设计，颠覆性地取缔了传统二维设计方法，设计成果也为纯三维铁路模型，仿真程度高；但铁路桥涵因其自身特点，在设计过程中，对里程、高程、净空、梁缝等外部数据，以及梁、墩台、基础的结构尺寸等内部数据的依赖程度很高，纯三维设计模式无法直接将这些数据展现在设计者眼前，设计者若想查看，必须先经过三维成果向二维成果转换或手动调出数据窗口才可以得到上述数据。

因此对于BIM桥梁设计，不宜完全摒弃二维设计方法。BIM铁路桥梁程序开发能够兼备三维理念和传统二维设计方法，同步生成二维设计成果以及进行三维建模展示或成为更加合理的设计模式。

另外，从程序开发角度来讲，BIM程序若能涵盖二维设计模式，可以更方便地与传统二维设计软件进行衔接，减少BIM程序开发工作量及开发难度。

而且二维、三维结合的设计模式，也可以使设计人员在新型的BIM设计环境下，能够利用自己熟悉的传统设计思路来迅速适应程序，从而提高程序应用效率，否则纯三维模式在铁路桥梁勘察设计领域的推广阻力和成本将会较大。本程序采用了二维视图交互设计，及三维视图显示的设计模式。

程序主界面

程序框架

MVC框架模式概述

程序以C++ MFC为开发工具，以MVC框架模式开发基于OpenGL的二维、三维视图显示功能。模型- 视图- 控制（MVC，Model-View-Controller）框架是图形用户界面（GUI，Graphic User Interface）程序的一种普遍的设计框架。采用MVC框架模式的优势是使得OpenGL渲染函数的调用从普遍的消息路由中完全脱离开来。

模型层

模型层是应用程序的核心部分，所有应用程序中的数据和定义应用程序行为的实现都被包含在内。最重要的是，任何指向视图层和控制层功能都没有被模型层引用，这意味着模型层是完全独立的。它完全无须关心视图层和控制层的行为，从而它只是简单地对视图层和控制层的请求进行加工操作。本程序中模型层负责全部的OpenGL顶点数据管理、顶点缓冲区对象（VBO，Vertex Buffer Object）绘图和图形更新。

视图层

视图层负责根据窗口设备环境创建渲染设备环境，最后将可视化的内容渲染到屏幕之上。视图层不含有指向控制层的引用（与控制层独立）。只有当控制层发送更新请求时，它才会执行渲染操作。然而，视图层需要有指向模型层的引用，因为它需要从模型层得到顶点、法向量、颜色等数据，这样才能将数据渲染到屏幕上。

控制层

控制层负责创建独立渲染线程，并对用户事件作出最直接的响应，它接受和处理所有的用户在窗体或视口中的操作，如鼠标和键盘输入等。为了处理用户事件，控制层需要访问具体的模型层组件和视图层组件。控制层组件通知模型层处理数据，同时告诉视图层更新显示的数据。另外，在本程序中，控制层还负责对用户事件相关的图元数据，如点、线、面、文字等，向OpenGL渲染数据进行转换。

显示功能关键技术

二维视图开发

十字靶标相对鼠标的同步定位

交互式设计视图开发中，如何将鼠标在屏幕窗体中的像素坐标（V）转换为视图中的世界坐标（W），是开发图形定位、图形选择的前提。转换公式的关键为计算窗体尺寸与视口所代表的世界坐标尺寸的比例vscale，当渲染视口与窗体边缘完全重合时，当前鼠标所在的视图世界坐标计算公式为：V = W ? vscale，当视口与窗体不重合时，还要计入视口相对窗体的起点偏移量（d），则视图世界坐标计算公式为：V = d + W ? vscale。

基于VBO的图形渲染

任何一个3D应用程序开发的最大的目标之一就是渲染速度，需要自始至终的将实际渲染图形的数量限制在最小范围内。除此之外，想简单提高多边形的提交速度的话，通常可以利用OpenGL提供的优化方法，顶点数组是一个比较好的方法。加上VBO的扩展，提高了渲染效率。使用顶点数组可以减少函数调用的次数和共享顶点的冗余使用，但其缺点是顶点数组中的函数位于客户端并且数组中的数据在它每次被引用时都需要发送到服务器端一次。而VBO在服务器端的高性能内存中为顶点属性创造了一个“缓冲区对象”，也就是说，VBO能够把数据加载到显卡的高性能显存中。因此当用户对桥梁方案编辑时，只要不改变顶点数量，如修改墩高、拉伸或缩短结构尺寸等，便可降低渲染时间。

CAD式的图形拾取效果

OpenGL提供了丰富的图形交互操作功能，可利用选择模式完成图形的拾取操作。对于拾取后如何标记显示，进而通知用户当前被选中图形的拾取状态，在程序开发中尝试了2种方法：（1）采用CAD的方式，将备选中图形显示成点状线状态；（2）采用达索系统的CATIA程序的方式，将被选中图形显示成高亮状态。

经过实际开发对比，前者可以非常好的利用VBO可提取并编辑顶点坐标的特点，只需要根据备选图形的VBO名称提取出相关顶点数组，之后无需跳出VBO模式渲染，直接以视口背景颜色按点状线样式重绘一次，即可达到与CAD完全一样的选中显示状态。而后者因为需要修改材质和光照状态，必须脱离VBO模式渲染，而且不易实现仅针对备选图形的OpenGL状态修改，所以程序选择了CAD式的点状线图形拾取处理方法。

三维场景空间索引

三维场景包括三维地形、桥梁结构、桥梁附属设施等模型，铁路三维地形为大型条带状模型，要求有比较高的交互性帧率来保证交互浏览操作时的渲染流畅性。因此，在渲染每一帧屏幕前，都需要对当前视景体所包含模型数据进行筛选，而且还要对无限视野下的模型数据进行分级简化，所以，只有采用合适的空间索引数据结构，才能提高渲染效率。

本程序采用的是比较适合于呈片状均布数据的四叉树空间索引。四叉树索引的基本思想是对空间数据递归划分为树结构，具体流程是，将当前空间数据等分成4个子空间，之后每个子空间递归划分下去，直到树的层次达到一定深度或者满足某种要求后停止分割。

4叉树索引比较简单，但是存在以下不足：（1）当空间数据对象分布不均匀时，会生成严重不平衡树，导致索引深度增加；（2）同一数据有可能被重复存储到树中多个不同节点之中，浪费存储空间。

因此，对四叉树模型做出以下改进：（1）规定空间数据仅保存在完全包含它的最小分割节点中，并且每个数据只能在树中存储一次，避免存储空间的浪费；（2）在创建树时，首先生成满四叉树，并限制四叉树深度，从而避免分配数据时临时插入节点而导致的内存重新分配损耗；（3）一次性将树的空节点所占内存释放掉。经过以上改进便可生成较为平衡的四叉树，改进后的四叉树模型。