王丽丽
（1.中煤科工集团常州研究院有限公司，常州 213000；
2.天地（常州）自动化股份有限公司，常州 213000）
目前基于WebGL 的三维矿山巷道可视化系统绝大多数采用在客户端完成数据采集、相交处理算法和建模成图等过程，然后将大量成图模型通过Object、JSON、GLTF 等主流模型文件格式导出，并在web 服务器端同步加载和渲染等过程以实现三维可视化[1-3]。这种方式实现三维可视化的场景模型其交互能力较弱，既无法做到参数化的动态建模和渲染过程，更不具备模型内部对象的操控和交互能力；
而且系统在配置和维护方面，完全依赖于客户端的建模成图服务应用，需要比较专业的绘图和维护人员完成中间过程才能应用到Web 服务器端，不属于真正意义上的基于WebGL 的应用，而仅仅是基于WebGL 的模型渲染系统；
要实现模型内部对象的操控和交互，就需要对模型按照细分粒度分类分割成较多的模型对象，增加了系统的建模和维护复杂度。对于井下巷道等大场景的系统，经过成图后输出的模型文件，一方面由于数量极大，另一方面由于井下水泵房、地面工厂等场景模型复杂，文件大小超1 G 以上，系统模型文件加载过程存在等待时间较长且极易阻塞情况，导致卡顿和交互体验不佳等问题。为此，提出了基于二进制空间分区树的井下巷道相交建模方法，构建矿井巷道虚拟环境在线建模和绘制渲染系统，可根据巷道拓扑参数动态建立巷道模型，避免了外部成图和模型文件输出的中间过程，可对模型内部的对象使用搜索、定位等方法实现更高要求的操控交互要求，解决了模型内部对象难以交互和操控的问题；
并以此为基础，提出一种基于web worker 多线程的大规模场景模型实时建模和加载方法，实施场景管理与建模分离策略，有效降低三维巷道系统的维护复杂度，避免因顶点数量和贴图材质多等超1 G 大场景模型的建模和加载时间过长，导致用户卡顿和交互体验不佳等问题，提升系统场景管理和实时漫游等功能的性能。
1.1 二进制空间分叉树（BSP）
二进制空间分叉树（Binary Space Partitioning）是一种使用超平面递归划分空间到凸集的一种方法。使用该方法划分空间可以得到表示空间中对象的一个树形数据结构。这个树形数据结构被叫做BSP树[4]。使用二进制空间划分（BSP）来组织场景中的对象，可以根据观察者的位置，快速地按照从前到后的顺序进行场景中对象地访问。在计算机辅助设计中，它被用来进行实体几何的构造。在机器人、3D 游戏、光线追踪中，它被用来进行碰撞检测。由于BSP 的特性，它常常被用来处理复杂的空间场景[5-6]。为此，采用BSP 树来对巷道模型进行实体几何的构造。
1.2 巷道截面及巷道绘制
对井下巷道的三维绘制采用巷道截面和路径扫描拉伸的方法实现。以半圆弧形截面为例，弧形巷道截面如图1，图1 中关键点坐标见表1。根据巷道截面及路径绘制巷道如图2，根据3D 直线绘制的巷道如图3，根据3D 曲线绘制的巷道如图4。
图1 弧形巷道截面Fig.1 Curved roadway section
表1 关键点坐标Table 1 Key point coordinates
选取2 个空间点O 和O’，以O 和O’为原点，根据巷道的高h、宽w 以及巷道壁厚度t 为参数值，通过二维坐标到三维坐标的变换，以及平移、旋转角度等矩阵变换，实现绘制出三维系统中的2 个巷道截面；
2 个巷道截面中心点O 和O’连成的1 条3D直线，沿着这条直线的路径，通过扫描拉伸的方式绘制成一段直线巷道（图2 和图3），而这段巷道的中心线也就是由这2 个空间点连成的1 条直线，这样绘制的巷道是直线巷道。井下巷道系统错综复杂，并非都是直线巷道，同样存在曲线延伸的巷道，这类巷道均采用贝塞尔曲线与Catmull-Rom 曲线插值算法从一系列点创建平滑的3D 曲线，再使用上文中类似的方法通过沿曲线路径扫描拉伸绘制成蜿蜒的曲线巷道（图4）。
图2 根据巷道截面及路径绘制巷道Fig.2 A roadway drawn according to the roadway section and path
图3 根据3D 直线绘制的巷道Fig.3 A roadway drawn according to 3D straight lines
图4 根据3D 曲线绘制的巷道Fig.4 A roadway drawn according to 3D curve
根据地测测绘采集的已知巷道空间点坐标及其拓扑关系等参数，通过上述方法，绘制出的基于WebGL 的三维井下巷道系统如图5。
图5 基于WebGL 的三维井下巷道系统Fig.5 Three-dimensional underground roadway system based on WebGL
1.3 巷道相交处理建模
井下巷道系统错综复杂，存在巷道与巷道之间相连接与相交的问题，通过前面方法建立的三维井下巷道，由于没有处理巷道与巷道之间的相交等问题，会出现巷道互相相交叠加的情况，需要对巷道之间相互连接的地方进行巷道的相交算法处理，为此，采用了二进制空间分叉树BSP 来对巷道相交进行实体几何的构造和建模。巷道相交处理后俯视图如图6，巷道相交处理后巷道内部结构图如图7，巷道相交处理后巷道内部透视图如图8。
图6 巷道相交处理后俯视图Fig.6 Top view after roadway intersection processing
图7 巷道相交处理后巷道内部结构图Fig.7 Internal structure of roadway after roadway intersection processing
图8 巷道相交处理后巷道内部透视图Fig.8 Inside perspective view of roadway after roadway intersection processing
找出2 个物体间的分隔面的方法适合于判断2个物体是否相交。如果分隔面存在，就没有发生碰撞，因此递归地遍历二叉树并判断分割面是否和包围球或包围盒相交，并还可以通过检测每一个物体的多边形来提高精确度[7]。进行这种检测最简单的方法是测试看看物体的所有部分是否都在分割面的一侧，并用笛卡尔平面等式ax+by+cz+d=0 去判断点（x，y，z）位于平面的哪一侧，如果满足等式，点在平面上；
如果ax+by+cz+d＞0 那么点在平面的正面；
如果ax+by+cz+d＜0 点在平面的背面[8]。在碰撞没发生的时候有1 个重要的事情需要注意，就是1 个物体（或它的包围盒）必须在分割面的正面或背面。如果在平面的正面和背面都有顶点，说明物体与这个平面相交。利用BSP 数据结构及其特性，可以很好地解决此类问题。
构造出符合实际情况的巷道拓扑相交，需要依据巷道的拓扑关系通过上文中描述的方法绘制的单段巷道和单段巷道之间，采用二进制空间分叉树BSP 对相交的巷道模型进行并集、差集等布尔运算，构造出巷道相交部分的实体几何，以实现巷道相交处理，并使用递归算法，依次对整个绘制的巷道实施相交处理、材质贴图和渲染等建模过程。完成相交、材质贴图和渲染的巷道内部视角图如图9。
虽然通过上述方法，系统可根据巷道拓扑参数动态建立巷道模型（图9），但在实际矿井巷道大场景中，巷道模型拥有的顶点数、三角面以万为单位计数，整个巷道相交建模的过程有着极大的计算量。这种在线建模耗费时间的复杂运算过程既依赖服务器电脑的CPU 性能，更需要服务器具有较高的GPU 渲染性能，这将给系统硬件带来极大的限制和投入成本。除此之外，耗费时间的复杂运算极易阻塞主UI 线程，给用户造成卡顿等较差的用户体验，上述问题亟需改善。
图9 完成相交、材质贴图和渲染的巷道内部视角图Fig.9 Interior view of roadway after intersection,texture mapping and rendering
在浏览器中JavaScript 的执行是单线程的，页面上的计算在执行时会阻塞浏览器的响应，非常影响用户的体验效果。虽然Ajax 技术的应用使页面在等待服务器响应的过程中不再发生阻塞，但还是没有改变其单线程运行的本质，依然不适宜把耗费时间的复杂运算放在页面上执行[9]。在需要等待计算结果或者大型文件加载的过程中，仍然容易出现阻塞的情况，为此提出了场景管理与建模过程分离的策略解决上述问题。采用Web Worker 多线程和分布式计算来实现分离策略。Web Worker 是内建在浏览器中的轻量级线程，允许把长时间运行和密集计算型的任务放在后台执行而不会阻塞UI 线程[10-12]。使用分布式计算执行相交建模计算过程不会阻塞事件循环，使在线建模和渲染系统应用运行更加流畅。
将绘制的巷道模型拥有的就数以万计的顶点和顶点，三角面和三角面之间的并集、差集等相交计算的过程，通过WebWorker 多线程，在后台采用模型文件的切片和分布式计算，实现主UI 线程与复杂计算线程的分离，将WebGL 计算和渲染效果依赖于电脑的显卡、内存和GPU 性能的因素降至最低，从而极大减轻了因计算量大而造成UI 阻塞而出现的界面渲染卡顿、掉帧的情况，并且更大程度地利用了分布式的性能特点[13-14]，解决相交建模过程中的因硬件条件有限的大算力计算等瓶颈问题。Web Worker 多线程策略如图10。
图10 Web Worker 多线程策略Fig.10 Web Worker multithreading strategy
Worker 线程之间不会共享作用域和资源，线程间的通信采用基于事件监听机制的消息队列。
服务器模块负责客户端、计算模块等发送的数据并进行处理，承担着JSON 格式模型文件切片、任务分解和分发、计算节点监控、计算结果的储存和汇总等分布式调度功能。计算节点作为守护程序监控计算模块程序实时状态，并且负责传递计算任务给计算模块。
计算模块负责处理计算任务，调用相应动态链接库或算法库完成计算过程，计算完毕后传输数据给计算节点。
客户端模块是用户与系统应用的交互，当用户进行UI 交互和数据查询时，服务器处理数据并返回给客户端，客户端接收数据并显示。
本次巷道建模Web Worker 分布式计算过程的性能测试采用4 台虚拟机在网络带宽100 M 环境下进行测试。虚拟机单台配置为单核，内存2 G，WIN10 操作系统。测试结果如下，在不进行分布式处理计算耗时为1 082 s，计算过程耗时很长严重阻塞界面UI。为了形成对比，将计算任务分配给不同数量的计算节点下进行测试。通过计算耗时分析整个建模分布式计算过程的计算效率，并以节点个数为1 的计算时间为基准计算时间。计算效率=理想计算消耗时间/实际计算时间=基准计算时间/（实际计算时间×计算节点个数），理想计算消耗时间=基准计算时间/计算节点个数。计算耗时折线图如图11，计算效率拆线图如图12。
图11 计算耗时折线图Fig.11 Time-consuming line chart
图12 计算效率折线图Fig.12 Efficiency line chart
由图11 和图12 可知：与不采用分布式计算相比，采用WebWorker 分布式计算可以极大的减少相交建模计算过程的计算耗时；
与此同时，随着计算节点数量的增加，计算耗时有明显的降低，而相同计算量的计算效率也会有一定的提升。
提出了基于二进制空间分叉树构造巷道实体几何实现巷道相交建模的方法和采用了WebWorker多线程技术，实施场景管理与建模分离的策略，实现了基于WebGL 矿井巷道虚拟环境的在线巷道建模和渲染系统。该系统根据参数动态建立巷道模型，有效地降低三维巷道系统在线建模的复杂度和维护难度，解决了模型内对象难以交互和操控的问题；
场景管理与建模分离的策略，使建模过程明显高效且缩短了大型场景模型的加载时间，缓解了用户界面卡顿和操作不友好等阻塞问题，提升了场景交互和实时漫游的效果和性能。