论文精读 3D world-model

#Vega 3D 详解

#一句话理解

Vega 3D 可以理解成 把 Vega / Vega-Lite 这类声明式可视化思路，延伸到三维空间中的一套图形表达方式：你不是直接逐点手写底层 3D 渲染逻辑，而是用更高层的数据、编码（encoding）、标记（mark）、场景（scene）和交互描述，去生成 3D 可视化结果。

如果你问的是某个具体项目、库、产品或论文里的 “Vega 3D”，不同上下文里含义可能略有差异；但从技术视角看，它通常围绕下面几件事展开：

用声明式方式描述 3D 图表
把数据字段映射到 3D 空间属性
支持相机、光照、材质、坐标轴、场景组合
提供交互能力，比如旋转、缩放、筛选、高亮
在可视分析、数字孪生、科学计算可视化中使用

#1. 背景：为什么会有 Vega 3D

传统 2D 图表系统（柱状图、折线图、散点图）已经非常成熟，但很多数据天然带有更高维结构，比如：

空间坐标数据（x, y, z）
时间序列叠加空间轨迹
网格 / 体素 / 曲面数据
分子结构、点云、工程模型
数字孪生场景中的对象状态

如果用传统 WebGL / Three.js 直接写，虽然灵活，但门槛高：

要自己写场景初始化
管理相机和渲染循环
处理数据到图形的映射
维护交互和状态同步

而 Vega 系列的核心价值一直是：

用户主要描述“数据如何变成图形”，而不是“像素如何绘制”。

所以 “Vega 3D” 的意义，本质上就是把这个思路带入三维可视化。

#2. 核心思想：声明式 3D 可视化

一个 3D 可视化系统通常至少包含这些层：

#2.1 数据层

输入的数据可能是：

表格数据：每一行是一个对象
几何数据：顶点、边、面
规则网格：高度场、体数据
流式数据：实时传感器/监控数据

示例：

[
  {"x": 1, "y": 5, "z": 2, "value": 18, "type": "A"},
  {"x": 2, "y": 3, "z": 7, "value": 24, "type": "B"}
]

#2.2 编码层（Encoding）

把字段映射到图形属性：

x → 三维空间 X 坐标
y → Y 坐标
z → Z 坐标
value → 点大小 / 颜色强度 / 高度
type → 类别颜色 / 形状

这和 2D Vega-Lite 的思路一致，只是可编码的视觉通道扩展到了 3D：

位置：x, y, z
大小：size, radius
颜色：color
透明度：opacity
形状：shape / glyph
方向：rotation
材质：material

#2.3 标记层（Marks）

3D 里的 mark 不再只是 bar, line, point，还可能扩展为：

点云（points）
立方体（box / cube）
球体（sphere）
线段 / 轨迹（line / path / trail）
曲面（surface）
网格（mesh）
体渲染（volume）
文本标签（text in 3D）

#2.4 场景层（Scene）

这是 3D 比 2D 多出来的关键部分：

相机（camera）
光照（light）
投影方式（perspective / orthographic）
场景容器（scene graph）
背景和环境贴图
深度测试、遮挡、裁剪

#2.5 交互层

典型交互包括：

轨道控制（orbit controls）
平移、缩放、旋转
点击选中对象
hover 高亮
框选 / 筛选
drill-down / 联动过滤

#3. Vega 3D 会解决什么问题

#3.1 降低 3D 可视化门槛

不是每个分析师都会 Three.js、Babylon.js 或原生 WebGL。声明式方式更适合：

数据分析师
BI 场景
科学可视化使用者
平台配置型开发者

#3.2 提高复用与组合能力

如果 3D 图表能像 Vega 一样被 JSON/DSL 描述，就更容易：

配置化生成
动态拼装
存储/版本化
跨系统传输
服务端下发规范

#3.3 统一 2D/3D 认知模型

理想状态下，用户可以用相似方式表达：

“把字段 a 映射到 x”
“把字段 b 映射到 y”
“把字段 c 映射到 z / color / size”

这样从 2D 迁移到 3D 的学习成本会低很多。

#4. 一个抽象的 Vega 3D 描述会长什么样

下面是一个 示意性的伪 DSL，不是某个标准官方语法，只是帮助你理解：

{
  "data": { "values": [
    {"x": 1, "y": 2, "z": 3, "value": 10},
    {"x": 2, "y": 1, "z": 5, "value": 20}
  ]},
  "mark": "sphere",
  "encoding": {
    "x": { "field": "x", "type": "quantitative" },
    "y": { "field": "y", "type": "quantitative" },
    "z": { "field": "z", "type": "quantitative" },
    "size": { "field": "value" },
    "color": { "field": "value", "scale": "viridis" }
  },
  "scene": {
    "camera": { "type": "perspective", "position": [3, 4, 8] },
    "lights": [
      { "type": "ambient", "intensity": 0.5 },
      { "type": "directional", "position": [10, 10, 10] }
    ]
  },
  "interaction": {
    "orbit": true,
    "tooltip": true,
    "select": "click"
  }
}

这个例子表达的是：

用球体表示数据点
点的位置由 x/y/z 决定
value 决定颜色和大小
使用透视相机
打开基本光照与轨道旋转交互

这就是声明式 3D 的典型思路。

#5. 和普通 2D Vega / Vega-Lite 的区别

#5.1 坐标系统复杂得多

2D 通常只有平面坐标和少量变换；3D 需要额外考虑：

世界坐标系
局部坐标系
相机坐标系
投影矩阵
深度排序

#5.2 感知负担更大

3D 图表不是天然更好。很多情况下它更容易：

遮挡数据
误导尺寸感知
让比较变难
增加操作负担

所以 Vega 3D 如果设计得好，不是“把图变炫”，而是：

在真正需要空间结构时用 3D
用声明式约束减少滥用
提供清晰的默认交互和视角

#5.3 渲染与性能问题更明显

2D SVG/Canvas 已经足够快时，3D 还要额外处理：

GPU 渲染
顶点数/三角面数
阴影与光照成本
picking / hit test
实时更新的帧率控制

#6. 典型应用场景

#6.1 三维散点图

适合展示 3 个连续变量，以及第 4/5 个变量映射到颜色和大小。

例子：

用户年龄、收入、活跃度
材料实验中的温度、压力、强度
模型 embedding 降维后的空间聚类

#6.2 3D 柱状图 / 立方体矩阵

把类别网格映射到地板平面，柱高表示数值。

适合：

空间热力分布
仓库/机房/楼层负载
地理格网数据

但也要注意：很多 3D 柱状图其实不如 2D 热力图直观。

#6.3 轨迹可视化

例如：

飞行轨迹
车辆路径
机器人运动路径
用户在虚拟空间中的移动轨迹

这类数据在 3D 中往往比 2D 更自然。

#6.4 曲面/等高面

例如：

地形高度场
数学函数曲面
工程仿真结果
温度场 / 压力场

#6.5 数字孪生 / IoT 场景

在建筑、工厂、园区、机房中，把实时指标叠加到 3D 对象上：

设备状态颜色
楼层能耗高度
告警对象闪烁
传感器实时数值

这类场景特别适合“数据驱动场景对象”的声明式表达。

#7. 设计一个 Vega 3D 系统时的关键模块

如果从系统设计角度看，一个较完整的 Vega 3D 通常需要这些模块：

#7.1 规范解析器（Spec Parser）

负责把 JSON/DSL 解析成内部表示：

数据源定义
marks 定义
编码规则
交互规则
场景结构

#7.2 数据变换引擎

类似 Vega 的 transform 流程：

filter
aggregate
join
bin
window
calculate
lookup

3D 不是只负责渲染，前面数据处理同样关键。

#7.3 场景图生成器（Scene Graph Builder）

把高层规范转成可渲染对象：

几何体
材质
坐标轴
标签
图例
容器节点

#7.4 渲染后端

可能基于：

WebGL
Three.js
Babylon.js
deck.gl
regl
原生 GPU API

声明式层和渲染层通常应该解耦。

#7.5 交互控制器

负责：

鼠标/触摸控制
拾取（picking）
事件分发
高亮/选择
tooltip 和联动

#8. 技术难点

#8.1 语义映射不如 2D 那么成熟

2D 图表里的柱、线、点语义非常清晰；3D 中“该用球体还是立方体、曲面还是体渲染”，常常依赖领域知识。

#8.2 遮挡问题

3D 最大的麻烦之一：

前面的对象挡住后面的对象
标签重叠更严重
某些角度下信息完全不可见

常见解决方案：

透明度
剖切/切片
动态标签
自动相机角度
focus+context

#8.3 性能优化

如果数据量大，会遇到：

几十万点点云
高频实时更新
浏览器显存限制
移动端渲染能力不足

优化手段包括：

instancing
level of detail (LOD)
批渲染
延迟加载
降采样
GPU picking

#8.4 可读性与误用

很多人一上来就想“把 BI 图表都做成 3D”，这是很常见的误区。

经验上：

如果核心任务是精确比较数值，2D 往往更好
如果核心任务是理解空间结构、路径、表面、层级关系，3D 更有价值

#9. 和几个常见 3D/可视化技术的关系

#Vega / Vega-Lite

强项：声明式、数据变换、图表语义
局限：传统上更偏 2D
Vega 3D 的设想：把声明式图形 grammar 扩展到三维

#Three.js

强项：通用 3D 场景开发
局限：太底层，图表语义要自己搭
关系：很适合作为 Vega 3D 的渲染后端之一

#deck.gl

强项：大规模地理空间可视化、图层化渲染
局限：更偏地图/图层范式
关系：某些 3D 数据图层可借鉴其 layer 模型

#Plotly 3D / ECharts GL

强项：现成 3D 图表组件
局限：表达能力和可组合性有边界
关系：它们更像“3D 图表库”，而 Vega 3D 更像“3D 可视化语法/规范层”

#Unity / Unreal

强项：复杂实时 3D 世界、沉浸式体验
局限：对数据分析师来说太重
关系：适合大场景应用，但不适合作为轻量声明式数据图表首选

#10. 适合用 Vega 3D 吗？判断标准

可以用下面这个简单判断：

#更适合 3D 的情况

数据本身是空间对象
需要表达轨迹、形体、体积、方向
用户任务是“探索结构”而不是“精确比较”
有交互条件（可旋转、缩放、筛选）

#不太适合 3D 的情况

只是为了“更酷”
用户主要关心精确数值比较
屏幕空间有限
用户缺少操作耐心
目标平台性能差

一句话：

3D 应该是认知增益，不是视觉装饰。

#11. 如果你要落地实现一个“Vega 3D”原型

一个实用路线可以是：

#第一步：先支持最小集合

数据输入
scatter / line / bar3d 三种基础 mark
x/y/z/color/size 五个 encoding
orbit 相机交互
tooltip

#第二步：补图表基础设施

三维坐标轴
图例
scale 系统
动画过渡
主题系统

#第三步：扩场景与性能

mesh / surface / volume
instancing
picking 优化
大数据渲染
linked views

#第四步：做生态能力

规范校验
编辑器 / playground
自动推荐图形
嵌入式 dashboard 支持

#12. 一个更现实的理解：Vega 3D 不只是“3D 图表”

真正有价值的方向不是简单做几个旋转的柱状图，而是建立一种统一表达：

数据语义层：字段、类型、变换
视觉编码层：位置、颜色、大小、形状、材质
空间场景层：相机、光照、层级、对象
交互层：筛选、选中、联动、注释

一旦这几层统一起来，Vega 3D 才能真正成为一种“3D 数据可视化语言”。

#13. 优点和局限，直接总结

#优点

抽象层高，开发效率更高
更适合配置化/平台化系统
降低 3D 可视化开发门槛
便于复用和组合
可以统一 2D/3D 数据表达思路

#局限

3D 可视化天然更难做好
可读性常常不如 2D
性能要求更高
交互设计复杂
通用语法设计难度很大

#14. 如果你是从产品、研发、架构三个视角来看

#产品视角

重点不是“支不支持 3D”，而是：

用户是否真的有空间分析需求
3D 是否能带来洞察增益
是否能控制学习成本

#研发视角

重点是：

规范设计是否足够稳定
和渲染引擎是否解耦
数据流和交互状态怎么管理
大数据量怎么保帧率

#架构视角

重点是：

spec 是否可存储、可下发、可版本化
是否支持 server/client 分工
是否支持多后端渲染
是否方便接入 BI、数字孪生、分析平台

#15. 最后给你一个直白结论

如果用一句更接地气的话概括：

Vega 3D 的核心不是“把图做成立体的”，而是“用类似 Vega 的声明式方式，把数据、空间、场景和交互组织成可复用的 3D 可视化规范”。

它的真正价值在于：

降低 3D 可视化实现成本
让 3D 图形从“手写场景代码”变成“可配置的数据表达”
在数字孪生、科学可视化、空间分析、实时监控等场景中形成统一语法

但它也不该被滥用。很多业务图表，本质上还是 2D 更清楚。

#16. 你如果想继续，我可以再补这几类内容

如果你愿意，我下一条可以继续给你其中任意一种：

从技术实现角度讲 Vega 3D 架构图
拿 Three.js / ECharts GL / deck.gl 跟 Vega 3D 做对比
写一个 Vega 3D 原型 DSL 设计草案
结合你现在的项目，分析 Vega 3D 应该怎么落地
给你画一版 Markdown 表格：模块、职责、输入输出