Unity3D虚拟现实交互制作（拓展） Unity3D虚拟现实交互制作（拓展） Unity中的VR实时图像捕捉.docx

Unity中的VR实时图像捕捉 本文将由Google VR高级工程师Jeremy Cowles，为大家分享VR绘图应用《Tilt Brush》中实时图像与视频捕捉功能的实现过程。《Tilt Brush》是Google使用Unity制作的VR应用，刚刚摘得了Unity Awards 2016的最佳非游戏项目大奖。 下面是Jeremy Cowles带来的分享： 在引擎中截取视频或屏幕截图，对游戏或图形应用程序来说是很好的分享功能，对于错误报告、社交分享或跟踪开发进度来说也很有帮助。 在Unity中，直接从游戏中截取视频帧不难办到。 然而，一个易于使用的API同时肩负重任。 对于那些开发VR内容并希望提供良好用户体验的人们来说，保持良好的性能是关键所在。 从Tilt Brush捕捉的4x超级采样渲染。 Sarah Northway绘制的“Space Dragon” 本文将说明如何仅使用C＃和Unity API实时截取合适的《Tilt Brush》视频，同时保持实现舒适的VR体验所需的90Hz高刷新率。我们使用自制的原生插件实现了该功能，但在实现原生插件之前，先尝试了解决C＃API中的问题。?? 在Unity中捕捉帧缓冲区需要使用RenderTexture和Texture2D。 之后复制像素很容易。 完成！每帧执行性能也很好！但这种做法在VR体验中不可行。 该过程运行慢的基本原因如下： GetPixels() 阻塞直到 ReadPixels() 完成 刷新GPU时， ReadPixels() 阻塞 每次调用GetPixels()都会分配一个新数组，垃圾回收器导致卡顿 在ReadPixels()和GetPixels()之间设置一帧的延迟就可以避免第一个问题，任何类型的传输都将在需要访问这些值之前完成。比较麻烦的是ReadPixels()会导致GPU刷新。 这是什么意思？当向GPU发出命令/绘制调用时，这些命令会被批处理到驱动程序中的批量命令缓冲区中。 “刷新GPU”意味着等待当前命令缓冲区中的所有命令执行。 CPU和GPU可以并行运行，但在GPU刷新时，CPU会保持空闲状态并等待GPU空闲，这就是它被称作“同步点”的原因。为什么会发生这种情况？如果使用NVIDIA的Nsight等性能分析工具，跟踪Unity对DirectX的使用，会发现ReadPixels()是通过调用CopySubresourceRegion后紧接着调用Map和Unmap来实现的。 Map读取CopySubresourceRegion结果很高效。正如DirextX文档所说，GPU复制可以流式进行，并且与CPU同时执行。 但如果在复制完成之前请求数据，则唯一返回同样值的方法就是完成所有待处理命令，从而强制CPU-GPU同步。从Nsight性能图中可以明显看到这种情况： 上图表示Unity API在强制同步，这个比较慢。由于我们知道这会强制同步，可能某些时候同步的开销较小。如果GPU已经是空闲状态呢？ 然后同步时间应该仅限于传输成本，这将远远小于等待所有或部分帧渲染完成所需的时间。在本例中，SteamVR也会强制同步，因此在某个点GPU是空闲的。这需要对渲染引擎有深入了解，类似Nsight的Frame Debugger或RenderDoc工具可以帮助探索黑盒中发生的事情。OnPreRender()看起来可靠，但是从下图中可以看出，该方法仅轻微提高了性能，然而在开始传输之前，CPU仍然会阻塞以等待某些任务完成： CPU-GPU同步2毫秒 这台相机不是场景中唯一的相机，因此GPU在OnPreRender()期间不一定处于空闲状态。我们知道SteamVR会强制同步，可以在SteamVR渲染循环协程中插入一个回调到自己的代码来复制像素。但测试之后还是2毫秒的同步，与之前截图一样。深入框架底层跟踪发现有一个早期的深度Pass、阴影Pass等。额外的相机才是真正的问题所在。 视频捕捉相机是在SteamVR渲染循环之外渲染的由于渲染循环实现了运行启动算法，所以额外的相机既搞乱了运行启动，也导致了GPU完全没有空闲时间。最后我们将额外的渲染和像素复制都移至SteamVR渲染循环中完成，在下面的截图中，同步时间已经减少到只与传输相关： CPU-GPU同步0.5毫秒 最终的事件序列如下： 渲染帧 Blit转为Render Texture作为后期效果 帧结束 在SteamVR渲染循环中，将Render Texture复制到Texture2D 在SteamVR渲染循环中，渲染第二个相机 等待一帧 在SteamVR渲染循环中，复制纹理Bit到C#中 请注意，我们需要三帧来实现该技术（对于90Hz的显示屏，截屏限制为30FPS），然而如果您的应用没有内存