Composer摄像机轨迹是关键帧插值结果，非算法生成；仅支持同一Actor上的position、rotation、focalLength三属性线性或Catmull-Rom插值，无跟踪约束与可调样条，导出后默认退化为线性，且基准为当前视图帧而非世界原点。
Composer 摄像机轨迹不是算法，是关键帧插值结果
Composer 本身不实现摄像机轨迹算法，它只做两件事：记录你手动打的照相机关键帧（位置、旋转、焦距），然后在播放时对这些离散点做插值。所谓“轨迹”，就是插值出来的中间状态序列，不是 CesiumJS 那种基于时间戳的 SampledPositionProperty，也不是 Blender 的贝塞尔曲线编辑器。
你看到的“平滑运镜”，完全取决于是否启用「平滑照相机路径」开关——关了就是线性跳变，开了才用 Catmull-Rom 样条拟合，但这个过程不可见、不可调、不可导出控制点。
- 关键帧必须打在同一个照相机 Actor 上，跨相机无法自动衔接
- 每个关键帧只存
position、rotation、focalLength三个属性，没有upVector或target字段，所以不支持“始终看向某零件”的跟踪约束 - 时间轴上拖动关键帧会重算插值，但右键 → “编辑关键帧”只能改数值，不能调入/出切线
为什么“平滑照相机路径”一开就卡顿
开启后 Composer 会在每帧实时计算样条插值，尤其当关键帧密度高（比如每 0.2 秒一个）或坐标变化剧烈（如俯冲+旋转组合）时，CPU 解算压力陡增。这不是渲染瓶颈，而是插值计算本身卡在主线程。
- 典型现象：时间轴拖拽流畅，但播放时掉帧，且卡顿集中在关键帧附近
- 导出 MP4 后反而顺滑？因为编码阶段做了帧采样，掩盖了运行时抖动
- 解决办法不是降分辨率，而是减少关键帧数量 + 把大角度旋转拆成多段小旋转（例如 90° 分三段 30°，比单帧 90° 插值更稳）
想让摄像机“沿轨道运动并盯住目标”，得绕开 Composer 原生机制
Composer 不支持摄像机绑定路径 + 跟踪目标的双重约束。它的照相机节点没有 trackTarget 属性，也没有 pathConstraint 接口。强行在时间轴上同步打“摄像机位置”和“旋转朝向”关键帧，极易因手调误差导致镜头漂移或翻滚。
真正可行的做法是：把摄像机当作普通零件，用枢轴绑定到一条隐藏的轨道模型上，再手动打位置关键帧；同时另起一条轨道，打一个固定不动的“目标空节点”，然后靠外部 JS（如发布为 HTML 后注入）调用 viewer.camera.lookAt() 强制对齐——前提是导出时勾选“启用 JavaScript API”。
- 隐藏轨道需用
opacity: 0或关闭可见性，否则会穿模 - 空节点不能是纯几何体，得是带 Transform 的 Actor，否则无法被 JS 定位
- 该方案仅适用于 Web 发布场景，本地 .smg 文件无法执行 JS
导出后的视角动画为何在网页里不连贯
Composer 导出 HTML 时，默认把摄像机动画烘焙进 cameraAnimation.json，但该文件只包含关键帧时间戳和 XYZ 值，不包含插值类型标识。浏览器端播放器按线性回放，即使你在 Composer 里启用了“平滑照相机路径”，导出后也退化为线性过渡。
- 验证方式：打开导出包里的
cameraAnimation.json，搜"interpolation"——基本为空 - 修复路径：导出前禁用“平滑照相机路径”，改用手动加关键帧（比如弯道处每 0.15 秒一个），确保线性插值也能逼近曲率
- 若必须高保真，放弃 Composer 自带动画导出，改用其
readyPromise回调，在 JS 中重建SampledPositionProperty并绑定到viewer.camera
实际最常被忽略的一点：Composer 的摄像机轨迹永远以“当前视图帧”为基准，而不是世界坐标系原点。你拖动一次视图再打关键帧，所有后续插值都会偏移——所以打第一帧前务必重置视图（视图 → 重置视图），否则整个轨迹漂移无法修正。
