★ FEATURED ARTICLE 项目跑进头显的第一版我盯着画面看了不到两分钟就摘下来了地面在往左斜扶手在往右倒虚拟物体的边缘还带一圈彩边。当时第一反应是模型导错了把美术同事折腾了半天最后发现问题出在最不该出错的地方——三维引擎相机。这也是我想聊这个话题的原因VR/AR/XR这些词听起来是硬件、是交互、是内容形态但真正决定了看着舒不舒服、对不对得上、跟不跟得住的是三维引擎相机这套东西。它决定了你把世界摆在哪里、用多大的视野去看、两只眼睛看到的差多少、真实镜头和虚拟镜头怎么对齐、头动完之后画面该信哪一帧的位姿。相机配错了再精致的美术资源也是白搭相机配对了一次后面所有内容都能复用。下面这些内容适合三类人看刚接手头显或移动端AR适配、对三维引擎只懂皮毛的开发者已经能跑通Demo、但一进真机就有各种说不清问题的同学以及做产品、需要判断技术边界在哪的设计和策划。我不打算从渲染管线第一章讲起而是按实际会踩坑的顺序把相机这件事拆开讲它到底在算什么、VR为什么非要两只眼睛、AR的虚拟镜头凭什么跟真实镜头对上、XR里相机位置为什么每帧都在变最后给一套能直接抄的调试清单。1. 相机不是摄像机它在三维引擎里承担三项计算很多人第一次接触三维引擎会把相机理解成摄影师站的位置。这个类比不算错但会误导你对参数优先级的判断。摄影师决定构图相机在引擎里决定的是三件事世界怎么被搬到眼睛坐标系下来、三维怎么被压成二维图像、哪些东西根本不需要画。这三件事分别对应视图矩阵、投影矩阵和视锥体裁剪任何一件算错表现出来都是画面不对但排查方向完全不同。先说一个最容易被忽略的前提相机本身没有位置只有一组变换矩阵。你在编辑器里拖动相机图标改的是这组矩阵的输入你写代码设置camera.position和camera.rotation引擎最终也是把它们合成矩阵再送进着色器。理解这一点很关键因为VR/AR里的所有追踪本质上都是外部设备在往这两个量里灌数据——追踪算法输出的不是一个位置数字而是一整套随时间变化的相机变换。1.1 视图矩阵把世界搬到眼睛坐标系下视图矩阵View Matrix做的事情是把世界坐标系下的点转换到以相机为原点、相机朝向为负Z轴的坐标系里。标准写法是相机变换的逆设相机旋转矩阵为 R、位置为 t那么视图矩阵等于 R 的转置左乘一个平移也就是[R^T | -R^T · t]。这个求逆的动作经常被写错尤其是自己手写相机的时候——很多人直接把相机位置塞进平移分量结果就是相机往右走画面往左跑。我在项目里用下面这段通用逻辑构建视图矩阵不依赖具体引擎移植起来很省事// 由相机的四元数姿态 q 和世界坐标 pos 构建视图矩阵列主序右手系 function buildViewMatrix(q, pos) { // 四元数转 3x3 旋转矩阵 R const { x, y, z, w } q; const xx x * x, yy y * y, zz z * z; const xy x * y, xz x * z, yz y * z; const wx w * x, wy w * y, wz w * z; // R行主序 const R [ [1 - 2 * (yy zz), 2 * (xy - wz), 2 * (xz wy)], [2 * (xy wz), 1 - 2 * (xx zz), 2 * (yz - wx)], [2 * (xz - wy), 2 * (yz wx), 1 - 2 * (xx yy)] ]; // 视图矩阵 R^T平移分量 -R^T * pos const tx -(R[0][0] * pos.x R[1][0] * pos.y R[2][0] * pos.z); const ty -(R[0][1] * pos.x R[1][1] * pos.y R[2][1] * pos.z); const tz -(R[0][2] * pos.x R[1][2] * pos.y R[2][2] * pos.z); return [ R[0][0], R[1][0], R[2][0], 0, R[0][1], R[1][1], R[2][1], 0, R[0][2], R[1][2], R[2][2], 0, tx, ty, tz, 1 ]; }注意这里的转置关系旋转矩阵的逆等于转置所以视图矩阵的前三行前三列应该是 R 的转置。上面代码里R[0][0], R[1][0], R[2][0]这一行取的是原矩阵的列刚好实现转置。这个细节一旦写反表现出来就是转头方向反了或者绕圈走很多新手会误判成追踪设备的问题其实只是矩阵转置错了。1.2 投影矩阵三维怎么被压成一张平面图投影矩阵Projection Matrix负责把视锥体内的点映射到标准化设备坐标也就是那个熟悉的 [-1, 1] 立方体。它决定的参数是视野角FOV、宽高比、近裁剪面、远裁剪面。这四个参数里真正影响观感的是 FOV 和宽高比影响精度的是近远裁剪面的比值。透视投影矩阵的经典形式是这样的列主序右手系映射到 -1 到 1 的深度范围function buildPerspective(fovYRad, aspect, near, far) { const f 1.0 / Math.tan(fovYRad / 2); const nf 1 / (near - far); return [ f / aspect, 0, 0, 0, 0, f, 0, 0, 0, 0, (far near) * nf, -1, 0, 0, 2 * far * near * nf, 0 ]; }fovY是纵向视野角aspect是宽高比。这两者的关系容易搞混大多数引擎让你传的是纵向 FOV然后根据屏幕宽高比自动推横向但头显设备和手机竖屏场景下很多人会下意识填横向 FOV结果视野被拉扁。在VR里这个错误尤其致命因为它会直接改变左右眼的视差比例进而破坏深度感知。提示近裁剪面不要小于 0.05远裁剪面不要大于 1000除非你的场景真的需要。近远比越大深度缓冲精度越差远处会出现闪烁的 Z-fighting这个问题在移动端XR设备上比在PC上明显得多。1.3 视锥体裁剪为什么转身之后模型就消失了视锥体裁剪Frustum Culling是相机系统里最容易被忽视、但直接决定性能的一环。引擎会用相机的六个裁剪面构造一个视锥体把包围盒完全落在视锥体外的物体剔除掉不送进渲染队列。这个机制本身没有问题问题出在VR和AR场景下视锥体会随着头部快速转动而剧烈变化如果包围盒算得不保守就会出现视野边缘的物体突然冒出来或者明明在视野里却被剔掉的现象。我遇到过最典型的一次是某个展示类项目里用户低头看脚下的展台展台会短暂消失半秒再出现。原因不是加载问题而是那个模型用了逐顶点的动态包围盒头部快速俯仰时上一帧计算出的包围盒已经不覆盖当前视角剔除判断在边界上反复横跳。解决办法很朴素给这类会动的、或者尺寸贴近视野边缘的物体手动设置一个偏大的静态包围盒宁可多画一点也不要让它闪。这里有个通用原则值得记住视锥体裁剪的正确性依赖相机矩阵和物体包围盒的一致性。如果你在VR里对左右眼分别做裁剪用的是各自的视图投影矩阵那没问题但如果你为了省性能只用中间眼或主眼的矩阵做一次裁剪给两只眼共用就要把视锥体稍微外扩一点因为左右眼的视锥体并不完全重合外扩的量大致等于瞳距在眼距方向上的投影。1.4 一个反直觉的结论相机参数该由内容决定而不是由设备决定刚接触这块的人常有一个误区头显设备的FOV是固定的所以相机FOV也应该照抄设备的FOV。逻辑上说得通实际上会让你很难受。设备FOV是物理光学参数指的是镜片能覆盖的角度相机FOV是渲染参数指的是你愿意画多大范围。这两者应该匹配但匹配的前提是你的渲染分辨率和性能预算撑得住。如果你在移动端XR设备上用满设备FOV渲染边缘像素会被透镜畸变拉伸得严重而且这些边缘像素对沉浸感的贡献其实很小。所以工业上的常见做法是渲染FOV略小于显示FOV然后通过畸变校正把图像重新映射到透镜上牺牲一点边缘视野换取中心区域的分辨率。这个取舍没有标准答案取决于你的内容类型——看文字的应用应该把预算全砸在中心看风景的应用可以把FOV开大一点。2. 双目相机VR的沉浸感来自两只眼睛的差异VR和普通三维渲染最本质的差别不是头显、不是手柄而是渲染管线要输出两张有视差的图像。这个视差两个字撑起了整个立体视觉。很多人以为VR就是把一个画面复制两份实际上左右眼的相机不是简单平移它们的投影矩阵、视锥体、甚至渲染时机都有讲究。这一块做不好轻则立体感很假、像在看纸片重则十分钟就头晕。2.1 左眼右眼各一台相机渲染开销的来源最直白的实现方式是左右眼各一台相机位置差一个瞳距IPD朝向保持一致。这种做法叫双通道渲染逻辑简单、兼容性好代价是场景要被遍历两遍、绘制调用翻倍。在PC上可能只是掉几帧在移动端一体机上是直接压垮性能的。所以实际项目里更常见的是几种优化路径我按落地难度排一下方案做法性能收益代价双通道渲染左右眼各渲染一次完整场景无绘制调用翻倍单通道双目一次绘制顶点着色器按视口索引选矩阵绘制调用减半需要着色器改造不透明物体收益大单眼渲染重投影只渲染一只眼另一眼用深度重投影生成接近减半遮挡边缘有伪影透明物体处理麻烦注视点渲染中心高分辨率边缘低分辨率像素填充降 30% 以上需要眼动追踪或固定注视点假设我最常用的是单通道双目因为它对现有内容的侵入最小。核心思路是把左右眼的视图投影矩阵作为一个数组传给着色器用gl_ViewID或者实例化索引去选一次绘制调用画出两个视口。这个改造在不透明几何体上的收益非常明显透明物体和后期特效还是得老老实实走两遍。2.2 瞳距参数设错十分钟就想摘头显瞳距IPD是左右眼相机之间的距离成年人通常在 58 到 72 毫米之间。这个参数决定了虚拟世界在深度方向上的尺度感。如果引擎里写死的 IPD 是 64 毫米而用户实际瞳距是 70 毫米会怎样虚拟物体的绝对尺寸看起来会偏小深度压缩感会变强近距离物体尤其明显——手柄伸到眼前时会觉得怎么这么快就到脸上了。更麻烦的是如果左右眼相机的 IPD 和设备的物理瞳距不一致大脑会持续收到矛盾的深度信号短时间内可能只是轻微不适超过二十分钟就是明确的眩晕。这个坑我在早期项目里踩得很实当时图省事直接写死 63 毫米测试时自己没事换了个脸型偏宽的同事试用五分钟就说眼睛累。正确的做法是从设备的运行时接口读取用户配置的 IPD或者至少提供一个可调的滑动范围。如果拿不到就提供一个校准流程让用户盯着远处一个固定物体逐步调整左右眼的偏移量直到双眼融合最舒服。听着很土但比硬编码强太多。注意IPD 影响的是相机间距不是相机位置的中心。改 IPD 的时候要保证两只相机围绕同一个中心对称移动否则虚拟世界会整体偏移用户会觉得世界在往一边飘。2.3 双眼时间对齐不同步的画面比模糊更难受除了空间上的差异还有一个维度经常被忽略时间。左右眼的图像如果不同帧哪怕只差一帧大脑在快速转头时也会感知到撕裂感或者重影。这在双通道渲染里是真实存在的风险因为两个通道如果分开提交中间可能插入了别的绘制任务。解决办法有两个方向。一个是保证两只眼在同一个渲染帧内完成中间不插入状态切换这是最稳妥的另一个是用时间重投影在接受一点误差的前提下提高帧率。后者的原理是用上一帧的渲染结果根据当前帧的头部位姿变化把图像warp到新的视角上。这个操作只做一次全屏的纹理采样代价极低可以在渲染完成到显示刷新之间补上几次把有效帧率从 72 提到 90 甚至更高。这个技术的坑在于遮挡。重投影只能移动已有的像素看不到原本被挡住的东西。所以快速转头时画面边缘会露出一条拉长的、模糊的带状伪影。工业上的做法是对边缘做额外的填充渲染或者干脆在边缘区域渲染一个更大的 FOV留出重投影的余量。这个余量一般取 5 到 10 度具体看你的转头速度上限。3. AR的虚拟相机必须和真实镜头对得上AR比VR多了一层麻烦你的虚拟相机不是孤立存在的它要和手机或眼镜上那颗真实的摄像头对齐。用户的期望很朴素——虚拟的杯子放在桌上就应该像真的摆在桌上一样位置不能飘、大小不能变、透视不能歪。要满足这个期望就得让虚拟相机的参数和真实镜头的光学参数一致这在术语上叫相机标定。3.1 内参标定焦距、主点、畸变系数的实际获取方式真实镜头的成像可以用针孔模型加畸变模型来描述核心参数是内参矩阵里的焦距fx, fy和主点cx, cy再加上径向畸变和切向畸变系数。这些参数不是猜出来的必须标定。标准流程是用棋盘格标定板从十几个不同角度拍摄提取角点用最小二乘求解。这套流程已经很成熟很多开源工具链都能直接跑。但实际项目里你未必有标定板所以有几个替代路径第一种直接从系统的AR能力里读。现在多数移动端AR框架都会暴露相机的内参虽然精度不如自己标但对多数应用够用。第二种用已知尺寸的参照物。比如在桌面上放一张A4纸拍摄后在图像里测量像素尺寸反推焦距。这种方法误差在 2% 到 5%做家具预览勉强够做工业测量不行。第三种出厂参数表。设备厂家的模组参数里通常有焦距和视场角但这个值往往是标称值实际个体差异不小。我一般的策略是先用系统接口拿一组基线参数再用简单的现场校准补正。现场校准的做法是让用户对准一个已知大小的矩形比如一张标准卡片检测四角反解焦距和主点。这个流程用户操作十几秒就能完成体验上可以接受精度比纯用系统参数好一个档次。3.2 外参和锚点虚拟物体飘在桌面上的真实原因内参解决的是镜头怎么成像外参解决的是镜头在世界里的位置和朝向。在AR里外参是每帧都在变的由视觉惯性里程计实时估计。你看到的虚拟物体在桌面上微微浮动原因通常有三个层次第一个层次是外参抖动。视觉里程计在纹理丰富的场景下很稳但对着纯色桌面或者白墙时特征点稀少估计结果会有高频抖动。表现就是虚拟物体在原地不停地小幅跳动。缓解手段是加滤波对位姿做低通或者卡尔曼平滑。但滤波有一个副作用相位滞后快速移动手机时虚拟物体会拖后腿。所以滤波强度要根据场景调静态展示可以重一点需要跟手交互的必须轻。第二个层次是平面检测误差。AR里的放在桌上通常是先检测水平面再在平面上放锚点。平面检测本身就是估计出来的它对距离的判断在近处准、远处差。如果你的虚拟物体尺寸很大锚点定在中心那边缘就会明显偏离桌面。这种偏差不是追踪的问题是平面估计的尺度误差。第三个层次是坐标系传递。如果你在多个锚点之间嵌套了父子关系误差会逐级累积。我见过一个案例虚拟家具的锚点挂在房间锚点下房间锚点挂在世界锚点下三层嵌套之后走到房间另一头虚拟家具偏移了将近十厘米。解决方案是尽量扁平化非必要不嵌套。3.3 透视视频和虚拟画面的分辨率、FOV 匹配AR里还有一个特别容易出戏的细节摄像头拍到的真实画面和引擎渲染的虚拟画面是两条独立的管线它们的分辨率、视场角、色彩处理都不一样。如果这两者没对齐用户会看到虚拟物体浮在视频上面而不是长在场景里。具体表现有几种。第一种是视场角不匹配真实视频的视野是 60 度虚拟相机设成了 65 度那靠近边缘的虚拟物体就会比它应该在的位置更靠内看起来像贴在屏幕上。第二种是宽高比不匹配视频是 4:3 裁切成 16:9 显示的虚拟相机用了完整的 16:9边缘就会错位。第三种是色彩空间不匹配视频是 sRGB 编码虚拟渲染是线性空间混合之后虚拟物体的暗部会比周围环境明显偏亮或偏暗。处理这类问题的思路是把真实视频当成一次全屏的背景绘制然后让虚拟相机的投影矩阵严格匹配视频裁剪后的有效区域。具体做法是拿到视频纹理的可见区域比例计算出对应的 FOV 和主点偏移再传给虚拟相机。这一步做扎实了虚拟物体的贴地感会有一个肉眼可见的提升。4. XR的头部位姿相机每帧都被重新摆放XR这个说法涵盖的范围比较大但落到相机系统上最核心的变化是相机不再由你控制而是由追踪系统每帧灌入。你的代码从设置相机位置变成了消费相机位姿。这个角色转换带来一堆新问题比如姿态怎么表示、延迟怎么补、长时间运行怎么不飘。4.1 四元数姿态与相机朝向的正确写法追踪系统输出的姿态通常是四元数。四元数的好处是没有万向锁、插值平滑坏处是不直观、容易写错乘法顺序。相机朝向的经典错误是把追踪姿态直接赋给相机的局部旋转而忽略了相机本身的初始朝向约定。多数引擎的相机默认看向负Z轴而追踪系统给的姿态可能是以正Z为前向的直接赋值的结果就是你往前看画面往后走。正确的做法是引入一个固定的校正旋转把追踪坐标系的前向映射到相机的前向。这个校正量对同一套设备是常量测一次写死即可。判断有没有配对的方法很简单戴上设备头往左转画面里的世界应该往右移如果反了就是校正旋转差了 180 度。还有一个细节是旋转的合成顺序。当相机挂在某个父节点下比如一个缩放的场景根节点追踪姿态应该作用在局部空间还是世界空间答案是局部因为追踪描述的是头相对于追踪原点的姿态而追踪原点在你的场景里可能被摆放到了任意位置。如果直接把世界空间的姿态赋给局部旋转父节点一缩放画面就会歪。4.2 位姿预测与重投影把延迟藏起来从你转动头到新画面出现在眼前中间有很长一条链路传感器采样、融合计算、应用逻辑、场景提交、GPU 渲染、显示扫描。这条链路的延迟通常在 20 到 60 毫秒之间。如果画面用的是你转头那一刻的位姿那你看到的就是一个 40 毫秒前的世界转头时会觉得整个世界在拖着你走。这个现象叫感知延迟是眩晕的主要来源之一。对抗手段是预测不等当前真实位姿而是根据历史数据外推一小段时间用预测位姿去渲染。最简单的预测是线性外推用最近两帧的角速度推下一帧。好一点的是二次外推考虑角加速度。但这个事不能推太狠推多了会在快速变向时过冲画面冲过头再弹回来比延迟还难受。预测之后还有一层保险就是前面提到的重投影。渲染用的是预测位姿显示前拿到真实位姿再算一次差异把图像 warp 过去。这一层能吃掉预测误差的大部分。两者配合的实际效果是预测负责把 40 毫秒的延迟压到 10 毫秒重投影负责把剩下的误差抹平到几乎感知不到。提示预测窗口不要超过 20 毫秒。超过这个值快速甩头时的过冲会非常明显而且一旦追踪短暂丢失预测会放大误差画面直接飞出去。4.3 长时间运行的定位漂移与锚点校正XR设备跑十分钟和跑两小时精度表现完全不同。视觉惯性里程计的误差会随时间累积表现是虚拟物体慢慢偏离原位。在半小时的演示里可能只偏一两厘米两小时的长时间使用就会明显到用户能察觉。对抗漂移的思路有几条。第一条是重定位当系统识别到之前见过的场景特征时重新对齐世界坐标系把累积误差一次性抹掉。这个机制很多运行时都内置了但触发条件依赖场景特征空旷或者重复纹理的环境不好用。第二条是外部锚点在场景里放一个可识别的标记二维码、特定图案定期校正。这招土但可靠适合固定场地。第三条是尺度和重力约束用IMU的重力方向持续修正俯仰角漂移这条对姿态漂移有效对位置漂移无效。我在一个展陈类项目里用过组合方案场内布置了若干标记点用户走到标记附近时自动做一次轻量校正校正过程不做画面跳变而是用几百毫秒平滑过渡。用户完全感知不到但两小时下来偏移控制在两厘米以内。5. 调试现场相机问题的排查清单前面讲的都是原理但真到现场你面对的往往是画面歪了物体飘了转头晕了这种描述。这一节把常见的现象和根因做成对照表再给一套调参顺序最后是一个最小验证场景方便你在新设备上快速确认相机链路是否正常。5.1 从画面反了到物体陷进地面的现象对照现象最可能的根因验证方法转头方向和画面对不上姿态校正旋转差 180 度头往左转看世界是否往右移画面整体倾斜视图矩阵转置写错或上向量不正交打印矩阵检查行列是否为单位正交虚拟物体比预期小IPD 偏小或投影矩阵 FOV 偏大用已知尺寸物体做对比测量远处物体闪烁近远裁剪面比值过大把远裁剪面从 1000 降到 200 再看边缘物体突然冒出来视锥体裁剪的包围盒过紧手动放大包围盒观察是否消失快速转头有拖影预测窗口过大或重投影缺失缩短预测窗口到 10 毫秒对比AR物体浮在桌面上内参或视频裁剪区域不匹配在桌角放虚拟立方体看底边是否贴合长时间使用物体偏移里程计漂移静止放置十分钟测量偏移量这张表我基本每个项目都会过一遍尤其是新设备第一次接入的时候能省掉大量猜的时间。5.2 相机模块的调参顺序为什么不能乱改调参最忌讳的是同时改多个参数因为相机参数之间是耦合的。我的固定顺序是这样的先定坐标系约定。右手还是左手、Y轴朝上还是Z轴朝上、前向是正Z还是负Z。这三件事定下来后面所有矩阵推导才有意义。再定投影参数。FOV、宽高比、近远裁剪面。近裁剪面按场景里最近的可交互物体来定比如手柄可能贴到眼前 10 厘米那就设 0.05 留余量。然后定相机间距。VR 里是 IPDAR 里是单目间距为 0。这一步要在投影参数之后因为 IPD 的视觉效果依赖 FOV。接着是姿态校正。只在校验过前向之后才动否则会把坐标问题误判成朝向问题。最后才是预测和滤波。这两者是调味料前面的骨架不对加了只会更乱。按这个顺序走每一步都有明确的验收标准坐标系用三个轴的箭头物体验证投影用已知尺寸的立方体验证IPD用近距离物体验证姿态用转头验证。全部通过之后再上预测。5.3 一个最小可运行的相机验证场景每次接入新设备或者新引擎我都会先搭一个十行代码就能描述的验证场景把所有相机相关的假设摊开验证。场景内容很朴素原点放一个 10 厘米边长的立方体颜色和背景对比强烈立方体脚下放一张一米的网格地面正前方三米处放一个一米高的立柱左右各两米处放一个不同颜色的球。这个布局能一次性暴露出大部分问题立方体验证尺度和 IPD网格地面验证水平面和倾斜远处立柱验证 FOV 和裁剪面左右球体验证视野边缘和遮挡关系。戴上设备走一圈转一圈头如果立方体的棱边是直的、地面是平的、球体在视野边缘没有变形、快速转头没有拖影那相机链路基本就是通的。这个场景我还习惯加一个开关能实时切换单目和双目渲染以及切换预测的开关。对比着看很多问题一眼就能定位到是哪一层出的问题。5.4 我踩过的两个印象最深的坑第一个坑是投影矩阵的深度范围。有一版内容在某个设备上跑近处一切正常远处的墙面会出现规律的条纹。查了很久以为是纹理问题最后发现是那个设备的图形接口把深度范围映射成了 0 到 1 而不是 -1 到 1我用的投影矩阵是按 -1 到 1 写的深度精度分布完全错位。这类平台差异在跨设备适配时特别常见现在我的做法是投影矩阵不手写优先用引擎提供的接口实在要手写就对着设备的图形接口文档确认深度范围约定。第二个坑是相机挂在缩放节点下。有个项目为了适配不同场地把整个场景根节点做了缩放。结果头显里的画面在快速转头时会出现轻微的比例抖动。原因是追踪姿态被应用在了缩放后的局部空间位置和旋转的缩放系数不一致。这个问题的解法是把相机节点从缩放层级里摘出来缩放只作用于内容不作用于相机。说白了就是一句话相机节点不要放在任何非均匀缩放的父节点下这条经验值很多次返工。再分享一个小技巧。调试相机问题时比起盯着最终画面猜不如直接把关键矩阵打印出来看。视图矩阵的旋转部分应该是单位正交的每列长度接近 1、两两点积接近 0投影矩阵的第三行第四列在透视投影下应该是一个非零的固定值。这两个检查用几行代码就能写能在几十秒内排除掉一大半低级错误。我在团队里推这个习惯之后相机相关的排查平均时间从半天降到了一个小时以内。最后说一句自己的体会。VR/AR/XR这几个词这些年被翻来覆去地讲硬件参数一年一个样但底下的相机逻辑其实非常稳定视图矩阵、投影矩阵、视锥体、双目视差、内外参对齐、位姿预测。这些东西不会因为换了设备就失效。把这块啃下来你换任何平台都是重新接一次接口的事而不是重新学一遍原理。我见过太多项目在相机上反复返工本质上都是把参数调一调就好了当成了解法而没有回到矩阵层面确认假设。花一天时间把这几个矩阵搞明白后面能省下的时间是以月计的。
阅读完成 · 觉得有帮助？
原理与实践：从数学基础到工程优化)
