企业官网建设流程全解析

年初接了个文旅项目的实景三维展示需求，甲方一句话说得很轻巧："你们把那边古建筑群扫一下，做成能在线看的模型。"结果一跑下来才发现，从无人机起飞到网页上能流畅转起来，中间隔着整个流程：倾斜摄影采集、空三解算、密集匹配、网格建模、模型修复、轻量化、格式转换、服务部署。每个环节都有各自的坑，任何一个掉链子，成果交付就卡壳。

圈里挺常见的现象是：无人机飞手觉得拍完照片就完成一大半了，建模工程师觉得模型跑出来就能交差，其实真正决定项目最终质量的，往往是收尾那几步——模型修复和网络发布。很多人建模出来一堆破洞、拉花、悬浮物，直接在浏览器里打开，观感非常糟糕；也有模型质量很好但发布后卡顿严重，根本没法用。这篇文章就把我从数据采集到最终网页展示的完整链路整理出来，每一步讲清楚为什么这样做、用什么参数、踩了什么坑，给想自己搞定"采集-建模-发布"全流程的朋友一个可直接参考的路线图。

1. 先建立全局认知：从外业采集到网页浏览的完整链路

1.1 一条龙流程里，三个环节各自解决什么问题

整个流程的核心价值，是把物理世界里的真实场景，变成浏览器里可以随意旋转、测量、标注的三维数字孪生体。这个目标拆开来看，正好对应标题里的三段：

倾斜实景三维建模解决的问题是"怎么把现实场景变成模型"。它靠无人机搭载的多镜头相机（通常是五镜头：一个下视加四个倾斜视角）从多个角度拍摄大量重叠照片，然后通过计算机视觉算法还原出场景的三维几何结构和纹理。这个阶段的输出是带有真实纹理的三角网格模型。

模型修复解决的问题是"怎么让模型变得干净可用"。倾斜摄影自动建模出来的原始模型，受限于拍摄条件和重建算法的局限，几乎必然存在水面破洞、玻璃拉花、边缘悬浮物、植被糊成一团等问题。不修复，模型就只能停留在"看个大概"的层次，没法用于测绘级量测或者对外展示。

成果网络发布展示分享解决的问题是"怎么让别人在任何设备上轻松查看"。原始建模数据往往是OSGB格式，动辄几十上百GB，普通浏览器根本直接打不开。发布环节要做轻量化处理、切片、格式转换，再配合服务器和前端框架（如Cesium），才能让用户打开网页就能流畅浏览。

三个环节是递进关系：建模决定模型下限，修复决定质量上限，发布决定最终能不能被用户用起来。任何一个环节掉链子，前面花的功夫都白费。

1.2 各环节常用软件和工具链快速摸底

我先把我常用的工具链列出来，后面每一个环节都围绕这套工具展开，方便你对照着落地。

这套组合的花费主要在建模软件授权和服务器带宽上，如果你预算有限，Metashape可以考虑标准版替代ContextCapture做建模，CesiumLab也有免费的社区版。工具不是越贵越好，关键是把流程跑通，后面我会在每个环节说清楚参数怎么调、坑在哪里。

细心的朋友会发现，这套链路里最容易被忽视的是"模型修复"这个中间环节。很多人以为建模软件跑完就完事了，恰恰是这一步决定了你的成果是"能看"还是"能用"。我甚至见过有人花了三天采集和处理数据，最后因为模型场景里有个大洞，甲方直接打回。所以下面我按照实际作业顺序，逐步展开每个环节的完整操作和背后的原理。

2. 倾斜摄影采集环节：影响模型质量的"半条命"在这里定生死

2.1 航高与地面分辨率（GSD）的换算关系

倾斜摄影的第一步是设计航线。很多人一上来就把无人机拉到120米高度，觉得"飞高点覆盖面积大，效率高"。但这个决定直接决定了模型的地面分辨率，而地面分辨率（GSD，Ground Sample Distance）是整个建模成果精度的基石。

GSD的计算公式很简单：

GSD = (传感器像元尺寸 × 航高) / 镜头焦距

举个例子，大疆Mavic 3 Enterprise的广角镜头传感器像元尺寸约3.3μm，等效焦距约24mm，如果飞到120米高度：

GSD = (3.3 × 10⁻⁶ m × 120m) / 0.024m = 0.0165m，约1.65厘米/像素

这个精度做一般的文旅展示、园区数字化完全够用。但如果项目要求达到1:500测图精度，GSD最好控制在1.5厘米以内，这时候就要降航高到100米以下。别小看这20米差距，它直接影响空三解算的匹配成功率以及最终模型的细节丰富度。

我个人的经验是：先明确成果用途，再反推航高。如果只是Web端展示，GSD做到2厘米就很细腻了；如果要支撑测量和竣工图，必须按1.5厘米以内控制。航高越低，照片数量越大，数据处理时间越长，这是一个需要综合平衡的参数。

2.2 重叠率设多少合适：航向80%、旁向65%不是拍脑袋定的

倾斜摄影对重叠率的要求比普通正射影像严格得多。普通测绘正射影像一般要求航向重叠60%-70%、旁向重叠30%-40%，但倾斜摄影要构建带有建筑立面信息的实景三维，所有侧面都必须被足够多的照片覆盖，这就需要更高的重叠率。

实测下来，城市级建筑密集区采用航向80%、旁向65%是比较稳妥的底线。为什么是这两个数？

• 航向重叠率决定同一地物在飞行方向上被多少张照片连续覆盖，80%意味着同一目标至少出现在连续5张照片中，空三匹配的特征点数量和稳定性才有保障；
• 旁向重叠率影响测区内部以及相邻航线间的模型衔接，低于60%容易在航线接边处出现模型错位或空洞。

如果你飞的是特别复杂的古建筑、异形钢结构这类结构物，我建议把航向重叠率提高到85%，旁向提高到70%。多拍的照片量大约增加30%，但后期处理时特征匹配的成功率会明显高出一截，最直观的表现是：墙角、檐口这类细节部位的建模精度高很多，修复阶段省事不少。

另外，社区里有一些人偷懒，建模时用正射影像的数据直接建三维，结果模型侧面全是黑洞。这事别干，侧面信息缺失是无法靠后期修复完整补回来的。倾斜摄影的核心优势就是多视角，采集时视角不够，建模阶段必露馅。

2.3 像控点布设与飞行执行的细节

如果你的成果只需要做展示，不要求绝对的测量精度，像控点可以省略，直接靠无人机RTK定位解算也能得到一套坐标一致的模型。但一旦涉及土方量测算、建筑尺寸量测、与已有测绘成果套合，像控点就必须老老实实布设。

像控点的布设原则是"区域网均匀分布、边缘加密"。以1平方公里建筑区为例，我一般布设5-6个平高控制点，测区四周和中央各一个，这样空三解算后平面和高程的误差能被约束在厘米级。选点时注意避开高反射面，比如白色地砖、玻璃幕墙边缘、水渍明显的区域，这些地方在影像上容易出现亮度饱和，刺点误差大。

关于刺点，有一个实操心得：不要只刺一张照片，每个像控点至少刺3-5张不同视角的照片。原因很简单，倾斜摄影同一个目标会在不同镜头中成像，多视角刺点可以约束相机之间的相对姿态和位置关系，空三平差结果更稳。只刺一张也能跑，但精度检查时容易出现系统偏差。

外业飞行要挑天气，光照均匀的阴天或多云天气是最理想的，顺光、逆光差别小，照片色彩一致性好。大风天（风速超过8m/s）不要飞倾斜航线，无人机会剧烈晃动，照片模糊率升高，空三解算时会出现大量匹配点丢失。

2.4 不同场景的采集思路：裸露地表、建筑密集区、植被区

单一"扫一遍"的思路只适合大面积空地。实际项目往往是混合场景，采集策略需要针对性地调整：

• 建筑密集区（如城中村、老城区）：建筑间距小，街道窄，无人机在120米高空拍不到建筑底层的完整立面，侧面纹理容易缺失。这种情况下，除了常规的倾斜航线，还需要补飞"环绕补拍"或者降低航高的"低空补盲"航线，重点覆盖建筑底部和背街巷道。
• 大面积水域（河流、湖泊）：水面特征点极其稀疏，空三解算时该区域极容易跑飞。采集阶段可以尽量选择有波纹、有船只、有倒影的时段，或者在岸边布设一些反差明显的标志物。后续建模和修复阶段还要专门处理水面，后面详说。
• 植被覆盖区（林地、公园）：树叶随风摆动，不同照片中的位置不一致，重建出来的植被区域容易变成一坨"糊状物"。采集时尽量挑无风天气，处理时也可以接受植被以"体块感"呈现，不必追求单片树叶的精度，否则点云和网格数据量会爆炸。

说白了，外业采集决定了数据质量的"天花板"，后面所有处理都是在尽量逼近这个天花板。基础没打好，内业再努力也只是缝缝补补。

3. 空三解算与密集匹配：照片是怎么变成三维模型的

3.1 空三到底在算什么

外业采集回来几百上千张照片，放进ContextCapture或Metashape，第一步跑的就是空三（空中三角测量）。空三做的事可以概括为一句大白话：从一堆只有像素坐标的照片里，反算出每张照片拍摄时的相机位置、姿态，以及场景中大量特征点的三维坐标。

这等价于求解一个大规模的最优化问题：系统自动在两两照片之间寻找同名特征点，比如屋檐角、路面标志线、墙面纹理的交点，然后用对极几何关系构建观测方程，经过多轮迭代平差，得到每张照片的相机参数（位置x、y、z和姿态角roll、pitch、yaw）。

跑空三时你会看到软件界面上慢慢生成一个稀疏点云，那些点就是被可靠匹配上的特征点。判断空三是否成功的标准不是"跑完了"就行，而是要看三个关键指标：

• 重投影误差（Reprojection Error）：通常要小于1像素，超过1.5像素说明有照片匹配不精准，需要检查是否有模糊照片或重复纹理；
• 连接点数量：稀疏点云中每个点被多少张照片看到，正常都要在3张以上，低于3张说明重叠度不够；
• 相机参数收敛性：迭代残差能否稳定下降，反复震荡说明初始值差或数据有问题。

我第一次用ContextCapture做空三时，跑完发现重投影误差跑到2.3像素，我直接忽略了继续建模，结果模型整体扭曲，部分建筑立面出现波浪状变形。后面排查才发现是外业时有二十几张照片对焦不准。解决方法是把那批模糊照片剔除后重新跑空三，误差降到0.7像素，模型才恢复正常。所以这一步别图快，严格把关，后面能省很多修复时间。

3.2 刺点和控制点检查的实操要点

如果采集阶段布设了像控点，空三后就要进行刺点操作。在ContextCapture里，每个像控点通常会被软件自动预测出现在哪些照片中，你只需要在预测的位置手动微调确认。实操中有几个细节容易踩坑：

• 刺点位置要选在两条地物边缘交点上，比如斑马线拐角、路缘石交叉处、地面标志线的端点。这些位置在影像上清晰且可重复定位，人眼和算法都能准确判断。平坦均匀的地面（如沥青路中央）很难精确到厘米级，别选。
• 控制点的"控制"作用有约束力差异：只参与平面（X、Y）约束的控制点和使用三维坐标约束的控制点，对空三结果的影响不同。我通常把外业RTK测量出的三维坐标全部输入，让控制点同时约束平面和高程，这样最终成果的绝对精度最稳。
• 检查点是另一组独立于控制点之外的点，空三平差不使用它们的数据，只用来验证精度。空三完成后查看检查点的平面中误差和高程中误差，平原地区一般要求平面中误差≤5cm、高程中误差≤8cm（具体以项目要求为准），超限了就要排查控制点坐标是否输错、刺点位置是否张冠李戴。

关于坐标系，国内常见的做法是使用CGCS2000坐标系加上1985国家高程基准。无人机自带RTK输出的坐标一般是WGS84经纬度，如果项目需要的是地方坐标系，空三前就要准备好坐标转换参数，转完再参与解算。这一步做错，后面所有成果的坐标都会偏，轻则重新导出，重则整个项目重跑。

3.3 密集匹配生成点云与网格建模

空三解算完成、精度验证通过之后，接下来就是密集匹配（Dense Matching）阶段。这一步的核心是：依据已经解算出的相机参数，将多视角影像中的像素逐一匹配，生成远超稀疏点云的密集三维点云。这些点的密度高到什么程度？基本上每平方米可以生成数百到数千个点，建筑表面的窗户、砖缝、管道等细节都能被刻画出来。

密集点云再经过网格化（通常是Delaunay三角网构建），把离散的点连接成三角形面片，形成连续的三维表面。最后，软件会把每个三角形面片所对应的照片纹理区域挑选出来，经过透视变换和色彩融合，粘到三角形上。到这一步，一个带真实纹理的三维网格模型就初步成型了。

建模阶段的参数设置，我建议重点关注这几个：

• 分块尺寸（Tile Size）：ContextCapture默认的模型分块可以根据电脑内存自动设定，但建议手动设置为100-200米范围一块。分块太大，单次加载计算量过大；分块太小，后续修复和发布时太碎。100米左右既可以保证单块细节密度，又不会让文件体积过于夸张。
• 纹理质量：Inv 建模阶段纹理图集一般选择2048×2048或4096×4096像素。2048通用性好，加载快；4096细节更清晰，但会显著增加贴图体积，浏览器加载压力变大。纯展示场景我建议直接2048，测量级别的项目可以局部区域用4096。
• 几何精度和纹理质量之间要平衡：有一些人为了提高清晰度，把所有纹理都拉到4096，结果一个几十GB的模型算完都困难，更别提发布到网上了。规划项目时就要想清楚最终交付形态，为发布预留压缩空间。

4. 初始模型的高频缺陷：破洞、拉花、漂浮物，问题根源逐个拆

4.1 水面和玻璃为什么总是翻车

自动建模软件搭建出来的初始模型，几乎必然存在各种缺陷。我在多个项目中遇到的缺陷种类高度一致，频率最高的是下面三类，先说水。

水面的问题根源在于：水的纹理特征随波光变化，不同角度的照片拍到的水面颜色、反光位置完全不同，特征匹配算法根本找不到稳定的同名点。结果就是水面区域要么生成一个大坑，要么生成一块扭曲变形的"马赛克面"，有时甚至是一个塌陷的深坑。

玻璃同样棘手，幕墙玻璃的镜面反射会让每张照片里呈现的是完全不同的天空和周边建筑倒影，算法以为是在匹配特征点，实际配的全是反射虚像，于是墙面上出现一团团"拉花"（几何扭曲、纹理漂移的区域）。

这两类问题在采集阶段只能缓解，无法完全避免，真正的处理是在模型修复阶段。预先有判断的好处是：修复时能快速定位问题区域，有目的地去补洞和替换纹理。

4.2 悬浮物和冗余地物怎么识别

建模范围内如果存在活动物体（移动的车辆、行人），或者地面杂物（锥桶、临时围挡），或者稀疏的树枝、电线，模型里就会出现极其难看的"悬浮物"。这些物体的位置在多次曝光中是不一致的，重建算法强行匹配后就会产生一团漂浮在半空中或者附着在模型表面的碎片。

识别悬浮物有一个高效的方法：在建模软件里把模型切换到无纹理的几何面片模式查看。纹理模式下一堆乱七八糟的东西可能被纹理掩盖，但切到纯色几何模式后，悬浮碎片会非常扎眼——它们往往以孤立的、悬空的三角形的形式存在，和主体表面没有连贯的几何连接。

这一步想说明一个更普遍的判断逻辑：实景三维模型是"数据驱动"的，哪里有可靠的影像信息，哪里才能建出可靠的三维几何。空中飘着的电线、细树枝、飞鸟，这些细碎物体的重建结果永远是"薛定谔的模型"——有时虚幻地存在着，有时完全消失。从业者的工作不是让它们全部重建出来，而是判断哪些该保留，哪些该删除，以保证模型整体观感。

4.3 纹理模糊与色彩分块的原因

除了几何缺陷，纹理问题也在初始模型里高发：

• 纹理模糊：多张照片拍摄同一面墙时，某张照片对焦不准或快门速度不足，导致图像模糊，算法自动选取纹理时会选到这些低质量照片的一部分。模型表面看起来像蒙了一层雾。
• 色彩分块：不同照片拍摄时的光照条件不同，即使同一面墙，在不同航线轨迹中的亮度、色温也不一致。纹理映射时如果边缘融合过渡不自然，就会出现一块亮一块暗的大色块。
• 接缝处纹理重影：相邻模型分块的纹理来自不同照片，在分块边界处出现明显的重影或者错位。

这些问题在自动修复阶段只能部分缓解，真正要改善还是得回到空三环节挨个检查照片质量。如果建完模才发现，那就只能进入纹理修复阶段手动处理。下面一节我会给出系统性的修复思路。

5. 模型修复实操：从自动清理到手工精修的方法论

5.1 先自动后手动：按缺陷类型分批处理

模型修复是最容易被低估的阶段，很多人觉得"不就是删点坏面吗"，实际做起来特别花时间。我总结出一套执行顺序，可以显著提高修复效率：先自动，再半自动，最后手动精修。

第一步，用建模软件自带的自动修复工具清理明显的大问题。ContextCapture自带的模型修复功能，或者DP-Modeler、Geomagic里都有"补洞（Fill Holes）""清理悬浮物（Remove Floating Objects）"等功能。自动处理能处理掉约70%的明显缺陷，包括孤立碎片、小尺寸破洞、部分悬空物。

第二步，针对自动修复处理不了的区域做半自动处理。比如大面积水面，我可以先在模型中把水面区域的边界线描出来，然后给这个区域的孔洞执行"平铺"或"压平"操作，生成一个平整的水面面片，再重新赋予周围相同的纹理。这一步不是修补，是重建——把不可靠的水面几何直接替换成人工定义的可靠几何。

第三步，手动修复重点区域的细节问题。建筑的屋檐下、门窗转角、浮雕细节等部位，如果出现小破洞或拉花，自动工具容易把周围特征一起抹平。这种情况只能一点一点用笔刷选择和三角面片编辑工具手工打磨。

关于工具选择：ContextCapture Editor对原始建模数据支持最好，但操作学习成本偏高；DP-Modeler在单体化修复和建筑规则化方面效率很高，适合城市建筑群；Blender有更灵活的多边形编辑能力，但需要先把模型从OSGB转成OBJ或FBX格式，适合对单个重要模型精细处理。

我自己的习惯是：大面积水面和悬浮物用DP-Modeler批量搞定，重点建筑单体的细节修复用Blender。如果你的场景不大，用一套ContextCapture Editor也能走完。

5.2 破洞填补与压平操作的完整流程

以常见的路面破洞修复为例，完整流程是这样：

1. 用选择工具把破洞周围的三角形面片选中，确保选中区域包含完整的完好边界；
2. 执行"填洞"（Fill Hole）操作，软件会根据边界生成新的三角面片；
3. 检查新生成的几何是否与周围地形平滑衔接，如果有高差或过度起伏，用"平滑/松弛"工具轻微处理；
4. 重新映射纹理。ContextCapture Editor可以根据周围纹理自动生成修补区域的纹理，但效果不稳定，必要时我直接把附近的完好纹理区域复制过来，用仿制图章的方式修改贴图；
5. 切换到纹理显示模式检查接缝，如果边界处有明显色差，用PS或者图像编辑工具做低透明度融合。

压平水面是另一套思路。我先用多边形选择工具把水面边界描出来，然后删除该区域内所有原始三角面片，接着用"生成平面"功能把这个区域的轮廓线原地展开成一个平面，最后给平面赋予水色纹理。效果跑出来就是一片平整洁净的水面，视觉上和周围堤岸、步道衔接自然。

如果水面区域范围特别大，比如整条河流穿过场景，建模出来的水面往往不是平面而是大量碎裂的坑洼面，这种情况用"补洞"是没用对的，因为洞的边界根本合不上。更适合的做法是：把河流整体范围建模成一个带坡度的连续曲面，用放样或沿边界生成曲面的方式重建，再赋予河面的流动纹理。这个操作在DP-Modeler里叫"水面拟合"，在Blender里可以用"Bridge Edge Loops"配合"Shrinkwrap"实现。

5.3 纹理贴图的修复思路：从PS到AI辅助修复

几何修复做完，纹理修复是提升模型档次的关键一步。实景三维模型的纹理是附着在三角网表面上的，是所有贴图图片的集合，所以修复纹理本质上是在修一张或多张位图。

最简单的纹理修复方式，是把贴图从模型上导出成常见的图片格式，然后在Photoshop里用仿制图章、修补工具把纹理上的斑点、破洞、色彩不一致的区域修掉，再贴回模型。这种方法适合小范围、局部纹理问题，操作直观，但效率很低，如果整个场景有几百张纹理要修，工作量会让人崩溃。

现在的思路升级了，可以引入AI图像修复模型来处理贴图中的缺陷。其实这就是"照片修复模型"的思路：利用生成式AI对图像缺失区域进行语义级别的重建和修复。做法是把纹理图集导出后，用LaMa或ControlNet这类图像修复模型，先标出需要修复的区域（比如水面上的死白反光、墙面上的拉花区域），AI会自动根据周围环境生成符合语义的纹理来填补。实测下来，对大面积玻璃幕墙的反射纹理修复效果尤其好，AI能合理推断出天空渐变过渡和建筑物轮廓，比手工仿制自然很多。

需要注意的坑是：AI修复对纹理的"连续性"要求高。如果只是修一小块区域，效果很好；但若修复范围横跨不同色温的照片拼接处，AI生成的纹理可能与相邻区域产生新的色差。我通常是先做分块统一色温，再让AI修复，最后整体调一遍亮度曲线，这样效果最好。

5.4 模型修复完成后的质量验收清单

修复完成不等于可以发布了，交出去之前我会过一遍验收清单，每项不通过就继续修：

• 几何层面：模型中是否还存在可见破洞、悬浮物、尖锐突起或凹陷；
• 纹理层面：是否有明显模糊、色差、重影、死白反光区域；
• 结构层面：关键建筑构件的轮廓是否清晰，墙角是否锐利，曲面过渡是否平滑；
• 水体层面：水面是否平整连续，与岸线衔接是否自然；
• 地物层面：道路、植被、路灯、雕塑等关键地物是否可清晰辨识。

验收时我习惯在软件里以"第一人称视角"绕着模型走一圈，这是最接近网页浏览视角的检查方式。你坐着旋转模型看，很难发现视角低矮处的缺陷；沿地面走一遍，所有问题都藏不住。

6. 发布前的模型体检：轻量化、格式转换与坐标校正

6.1 原始工程数据与发布数据的差异

模型修复完成后，你手里的成果可能还是一个巨大的原始工程文件——ContextCapture的工程里，OSGB格式的瓦片加起来轻松超过50GB。这种数据没法直接发布到网上，因为浏览器端3D渲染对模型的加载能力和显卡渲染压力有严格要求。

发布数据和原始数据存在三个核心差异：

1. 格式不同：原始OSGB、S3C格式无法直接被浏览器识别，需要转换为3D Tiles格式（目前Web三维最主流的开放标准）；
2. 规模不同：原始数据是全细节、全尺寸的，发布数据需要做LOD（Level of Detail，细节层次）金字塔——远处加载低精度模型、近处加载高精度模型，让浏览器按视距动态调度；
3. 压缩程度不同：发布数据要进行纹理压缩和顶点压缩，通常能把原始数据体量压缩到1/5甚至1/10，但保留足够的视觉细节。

发布前的数据处理，本质上就是一次"为了Web端浏览体验而做的定向优化"。

6.2 LOD层级与纹理压缩的取舍

LOD的概念可以这样理解：你看一个城市模型的全局时，只需要加载粗糙的整体轮廓；当你放大到一栋建筑时，才需要载入这栋建筑的精细纹理和几何细节。3D Tiles把模型按空间范围切成多棵"树"，树的每个节点存了一个层级的模型数据，浏览器根据相机位置和距离动态决定加载哪一层。

我通常在CesiumLab或者osgb23dtiles工具里把LOD层级设置为12到15级。层级太少，远处模型模糊、近处细节少；层级太多，切片文件碎片化严重，网络请求数暴增，加载效率反而下降。关乎LOD层级的另一个参数是"最大屏幕空间误差"，默认值是16像素，如果希望模型近看更精细，可以设成8像素，但文件体积会略增。

纹理压缩是另一个重点。原始OSGB的纹理一般是JPG或PNG，尺寸很大，发布时可以统一压缩成WebP格式，在同等视觉效果下体积比JPEG小30%-50%。如果对兼容性有更高要求也可以继续用JPEG，但质量参数建议压到75-80之间。这里要克制"越高越好"的念头，Web端浏览对带宽和显存的限制是硬约束，高质量贴图带来的视觉提升会被加载卡顿完全抵消。

6.3 OSGB转3D Tiles的具体流程与踩坑

以CesiumLab为例，OSGB转3D Tiles的基本流程如下：

1. 新建"通用模型"处理任务，选择OSGB数据根目录；
2. 设置坐标系为原始项目坐标系（一般是CGCS2000/UTM或地方坐标系），注意要正确填写EPSG代码，坐标错位是这里最常犯的错误；
3. 设置LOD层级、纹理压缩格式、空间误差等参数；
4. 开始转换，生成一个带tileset.json的3D Tiles文件夹；
5. 将生成的文件夹上传到Web服务器，就可以在Cesium中加载了。

踩坑记录：

• 坐标系混乱：OSGB里可能存储了双份坐标信息——一份是地理经纬度，一份是投影平面坐标。转换时如果选错基准，模型在网页里会偏移到海里。解决办法：转换前确认项目的坐标系统，最好和原始建模工程里的坐标系保持完全一致。
• tileset.json缺失或引用错误：所有层级文件都依赖tileset.json这个入口文件来索引。上传服务器时注意不要单独传输某个瓦片文件夹，必须保持整个目录结构完整。
• 纹理类型不受WEB支持：旧版本OSGB里可能带有TIFF纹理，浏览器不支持，转换后会出现大片粉色或灰色模型。最终在发布前，用3D Tiles调试工具看一眼所有层级是否都正常。

如果你不想用CesiumLab，也可以用开源工具链：先用GDAL把坐标信息和范围提取出来，再用Blender或MeshLab把OSGB转成glTF，最后用obj23dtiles这类工具转成3D Tiles。开源路线灵活但步骤更杂，适合喜欢折腾的朋友。

7. 网络发布的完整落地：从服务器配置到浏览器三维浏览

7.1 静态文件托管与目录结构

3D Tiles本质上是静态文件资源，发布它只需要一个能托管静态文件的Web服务器。Nginx是首选，安装完成后在配置里指定一个站点根目录，把3D Tiles文件夹放进去即可。

合理的目录结构参考：

/var/www/3dtiles/ ├── scene1/ │ ├── tileset.json │ ├── L12/ │ ├── L13/ │ └── ... ├── scene2/ └── ...

有一个非常重要的点：Nginx需要正确配置MIME类型，tileset.json和.b3dm、.glb等文件都必须被识别为正确的Content-Type。漏配了MIME类型，浏览器请求资源时会报错或者无法解析，这是最常见的发布失败原因。

我做发布时会加上三个优化配置：开启Gzip压缩、开启静态文件浏览（方便排查）、设置合理的缓存过期时间。Gzip对JSON类型的tileset索引文件压缩效果极好，能在网络传输层面再省一部分开销。

7.2 CesiumJS加载3D Tiles的代码实践

前端展示我用的最多的是CesiumJS，它是目前Web三维地球和实景三维浏览的事实标准。加载3D Tiles的核心代码如下：

const viewer = new Cesium.Viewer('cesiumContainer', { terrainProvider: Cesium.createWorldTerrain(), baseLayer: Cesium.ImageryLayer.fromProviderAsync( Cesium.ArcGisMapServerImageryProvider.fromUrl( 'https://services.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer' ) ), infoBox: false, }); try { const tileset = await Cesium.Cesium3DTileset.fromUrl( 'http://your-server.com/3dtiles/scene1/tileset.json' ); viewer.scene.primitives.add(tileset); viewer.zoomTo(tileset); } catch (error) { console.log('加载失败：', error); }

加载后第一个要检查的问题是坐标是否漂移。如果模型位置不对，不要急着改前端代码，先回到tileset.json里检查其transform矩阵是否正确，以及坐标系是否与前端场景匹配。Cesium默认使用WGS84坐标系，如果你的原始数据是地方坐标系，转换时就要把坐标转换为WGS84或者CGCS2000的经纬度，再配合高度改正，模型才能落在正确位置。

另一个常见问题是模型整体上下浮空或者陷入地下。这通常由高程基准不一致引起，解决方案是检查tileset.json中的height偏移，或者在Cesium中给模型加一个模型矩阵修正。我习惯在CesiumLab转换时为z轴加一个平移参数，把模型整体压低或抬高到地表合理位置。

7.3 高程、影像、模型三类服务的配合

一个完整的实景三维展示页面，往往不只是加载倾斜摄影模型本身，还需要配合使用影像底图、地形高程和标注信息，才能让浏览者准确理解场景。

• 影像底图：提供全局框架感，让用户在未加载出模型的区域仍有地理参考。可以使用公开的影像服务，也可以用GeoServer发布自己的正射影像切片；
• 地形服务：如果模型周边有更大范围的山地地形，可以单独发布地形切片（Terrain Tiles），让模型和真实地形之间形成平滑过渡，而不是模型边缘突然消失；
• 模型服务：即3D Tiles本身，是场景的核心内容；
• 标注/兴趣点：在Cesium里通过Entity API添加点、线、面标注，比如建筑名称、测量点、游览路线等。

三类服务配合的原则是：模型管精细，地形管过渡，影像管全局。模型加载范围外显示影像底图，模型边缘接地形处做透明融合，加载过程中用户始终看到完整的地球背景，而不是一片空白。

7.4 性能优化与浏览器端加载体验

模型发布上去后，性能优化决定了最终用户体验。常见瓶颈有三个：网络传输、GPU渲染、内存占用。对应的优化手段也围绕这三点：

• 网络传输优化：开启Gzip/Brotli压缩；把服务迁移到CDN；合理设置浏览器缓存；缩小单次请求的瓦片体积。
• GPU渲染优化：减少模型顶点数，适当提高最大屏幕空间误差值；控制同时加载的3D Tiles数量，让Cesium自动调度；不要同时叠加多个高精度图层。
• 内存占用优化：降低纹理贴图分辨率；限制最大加载纹理缓存；浏览器端设置合适的缓存清理策略。

我实测过一个城区级模型，原始OSGB约45GB，转成3D Tiles后是6.8GB，再经过WebP压缩后服务端存储约4.2GB。同样一段5分钟浏览路径，优化前每帧加载瓦片数量峰值约320个、帧率平均26帧/秒、内存峰值约1.8GB；优化后峰值瓦片数量降到150个左右、帧率稳定在46帧/秒以上、内存峰值降到约1.1GB。差距非常明显。优化不必一次到位，可以先保证能打开，再根据真实用户的反馈逐步调参。

发布后的日常维护也要纳入考虑。3D Tiles是静资源，只要数据不更新，服务器一般不会出大问题。但如果项目需要频繁更新模型（比如施工进度对比），建议把发布流程脚本化：修改后的建模数据跑一次转换脚本，自动覆盖线上瓦片目录，几行命令搞定，避免每次手动导出上传的重复劳动。

我在实际项目里最后养成的一个习惯是：发布完成后用手机流量而非Wi-Fi再测一遍页面加载速度。办公Wi-Fi带宽充足什么都快，但甲方很多人会在地铁、户外用流量打开链接，这种场景下的加载速度和缓存策略才是真正考验。把这一关过了，模型发布这件事才算真正干完。