判断 ABot-Earth 0.7 能不能落地,可以先不看画面好不好看,把问题压到两件事上:同一栋建筑换成相邻视角后结构还连不连续,以及一次生成覆盖到城市级范围时,你的机器能不能把它跑完并留住结果。前者决定展示能不能上台面,后者决定它是演示工具还是能进流程的工具,两件事各自都可以用截图、计时和资源记录来复核。
先做两个动作再谈落地:固定同一片区,按左、中、右三个视角截图,逐项对比门窗、屋顶和道路边线是否连续;再用自己手上的三维数据做一次同等规模加载,记录内存、显存和帧率变化。两项都能稳定通过,才有继续验证的价值;任一项明显漂移或吃满资源,建议先按展示用途使用,不要直接接进生产链路。
从三个连续视角截图对比同一建筑
多视角一致性靠肉眼就能查出相当一部分问题,前提是固定变量。建议在同一片区内选一栋结构清晰的建筑,相机高度、焦距、截图分辨率保持不变,只改方位角,按左、中、右三个视角各截一张。生成时如果工具支持固定随机种子,先固定;不支持的话,同一视角重复生成两次,先确认单个视角自身是否稳定,再判断跨视角漂移。
记录时按构件分项,不要笼统写像不像。门窗数量与排列、屋顶坡向与檐口线是否闭合、道路边线在建筑两侧是否对齐,这三类最容易暴露结构漂移。常见表现是同一栋楼在左视角两扇窗、右视角变三扇,屋顶脊线方向翻转,或者道路边线绕到建筑背后就错位。把这些记成表,比事后凭印象争论有效。
| 观察项 | 左视角 | 中视角 | 右视角 | 连续性判断 |
|---|---|---|---|---|
| 门窗数量与排列 | 记录实际数量与位置 | 同左 | 同左 | 数量一致、相对位置不跳变 |
| 屋顶坡向与檐口线 | 记录朝向 | 同左 | 同左 | 坡向不翻转、檐口线能闭合 |
| 道路边线 | 记录与建筑的关系 | 同左 | 同左 | 建筑两侧边线能接上 |
截图文件建议按区域和视角命名,方便回看。下面只是整理目录用的骨架,路径按自己的环境替换:
mkdir -p shots/block-A
# 同一区域、同一相机高度,仅方位角不同
# left.png / center.png / right.png 放同一目录
ls -l shots/block-A
判断边界:三张图连续只能说明该片区在该尺度下没有明显穿帮,不代表换个片区或拉远视角仍然成立。要扩大结论,建议再换两个结构不同的片区重复同样动作;只测一栋楼就下判断,风险偏大。
记录一次生成覆盖的范围与耗时
城市级数据量很难直接从界面上的宣传数字判断,更稳的做法是记一次真实生成的观察口径。范围只记可观察的部分:生成结果里能辨认多少街区、地图上圈出的边界框大致多大、是否出现明显未覆盖的空洞。不要把这些换算成参数量或模型内部指标,那些数字通常不可核验。
耗时按人工计时记三项:从提交到出现第一批可见结果的时间、到整体结束的时间、等待过程中界面是否还能操作。交互流畅度用拖动和缩放时的顿挫感描述,能记帧率就记帧率,记不到就写主观等级并注明是主观判断。
| 记录项 | 记录口径 | 怎么测 |
|---|---|---|
| 覆盖范围 | 可辨认街区数量、边界框、空洞位置 | 截图或地图上圈出边界 |
| 等待时间 | 首帧出现时间、整体完成时间 | 人工秒表或系统时间差 |
| 交互流畅度 | 拖动、缩放是否顿挫 | 主观等级,能记帧率则记帧率 |
验证动作:同参数重复一次,看耗时波动是否在可接受范围;把范围扩大一档,例如多包一两个街区,观察耗时和资源占用是不是明显上升。如果只是变慢,还能靠等解决;如果出现卡死、掉结果或需要重启,说明已经接近当前配置的上限,需要结合你的机器再确认。
在本地尝试加载同等规模的三维数据
与其猜自己能跑多大,不如用已有三维数据做一次对照加载。手上有倾斜摄影、点云或模型都可以,选规模接近你期望生成范围的那一份,在本地加载并观察资源变化。这是验证本地上限最直接的动作,不需要硬接任何官方接口。
先记录加载前的基线,再在加载中和加载后重复采样:
# 加载前
free -h
nvidia-smi `--query-gpu`=memory.used,memory.total `--format`=csv
# 加载过程中另开一个终端持续采样
watch -n 1 'free -h; nvidia-smi `--query-gpu`=memory.used `--format`=csv'
帧率如果没有现成面板,可以在页面控制台里临时计数:
let last = performance.now(), frames = 0;
function tick(now) {
frames++;
if (now - last >= 1000) { console.log('fps', frames); frames = 0; last = now; }
requestAnimationFrame(tick);
}
requestAnimationFrame(tick);
要看的不是某一个瞬间的峰值,而是加载完成后能否稳定下来:内存是否持续上涨、显存是否贴近上限、帧率是否长期低位。显存打满时通常会回落到内存或直接失败,系统开始使用交换分区只说明在止血,不代表这套规模能长期跑。具体阈值需要结合显卡型号、内存容量和数据格式确认,同样的数据换成不同格式,资源表现可能差不少。
把「可展示」与「可生产」分开列项
落地判断容易糊在一起,是因为展示效果好和生产可用被当成同一件事。建议分开列,每一栏都写能复核的证据,而不是写主观评价。
| 维度 | 可展示的标准 | 可生产的标准 |
|---|---|---|
| 展示效果 | 选定片区内三个视角结构连续,无明显穿帮 | 多片区、多尺度重复检查后仍稳定,且知道失效边界在哪 |
| 可导出程度 | 能导出图片或视频用于演示 | 能导出下游可用的模型或结构化数据,格式和坐标系明确 |
| 可重复生成程度 | 同一区域重新生成一次,观感大致接近 | 固定参数和输入后结果可复现,差异范围可接受且有记录 |
填这张表时,建议只写有截图、日志或命令输出支撑的内容。展示效果一栏可以偏宽松,因为它面向好不好看;可导出程度和可重复生成程度要偏严格,因为它们决定下游能不能接。两栏之间出现明显落差时,常见的处理是保留展示用途,生产环节继续走原有流程,等边界摸清再逐步替换,而不是一次性切过去。