帮助开发者获得成功，Unity新产品介绍 — ArtEngine、Plastic SCM、Backtrace

昨天，Unity 2020.2 技术更迭版正式发布，为广大开发者带来革新式的创作体验（点击回看）。除了Unity编辑器，我们还提供了众多好用的产品、插件等等。

在Unit线上技术大会中，Unity大中华区技术客户经理（华南&西南）司徒杰就为大家带来三款Unity新产品介绍，它们分别是ArtEngine、Plastic SCM 和 Backtrace。以下为演讲实录：

Hello，大家好！欢迎来到中国Unity线上技术大会游戏专场。我是Unity大中华区的技术客户经理司徒杰，负责华南和西南的客户，主要是企业支持和定制化的跟踪。今天我要给大家分享的是助力开发者成功—— Unity新产品介绍，ArtEngine，Plastic SCM，Backtrace。

那什么是ArtEngine？ArtEngine是AI赋能的高效材质创作工具。ArtEngine利用AI来辅助美术创作，可以自动实现和加快将照片转化为基于物理的渲染PPR材质的过程，包括提高分辨率，去模糊、接缝清除、展平或者是色彩匹配等等。

我们先看一下这张图。这张图是在现实拍到的实际的东西，我们使用ArtEngine把它转化成了一张可以用在游戏里面的贴图。

ArtEngine的界面是这样的，是一个基于节点式的自动化贴图处理工具，它是AI赋能、基于机器学习的功能制作的。

使用ArtEngine的客户主要有EA、动视、腾讯、EPIC，还有育碧等等。

ArtEngine的制作流程是怎样的呢？它是基于扫描的PBR工作流程。首先我们要进行Surface Capture，这里是scanning，如果是高精度的就是一些材质表面的扫描，又或者是通过手机或者是照相机来进行材质表面的抓取。

接下来我们通过DXO的Photo Lab进行Image PhotoEditing，就是需要编辑一下照片。然后再通过Metashape进行Photogrammetry Reconstruction，就是所谓的摄影制量法，然后转换成一张可以用于游戏中的贴图。

这个时候我们再通过ZBrush来去制作Build and uvmapping。然后，我们再把它导进像3D MAX或者是Maya等等里面进行Lowpoly Model Texture Baking，就是我们平常所说的拓扑。

接下来是ArtEngine插入的阶段。在这个步骤，我们在制作贴图的时候可以做Seam Removal、Material Tiling、Surface logic、Final PBR texture，就是可以做一些接缝消除，然后把纹理变成可循环。

还有输出最终的PBRtexture，我们把它导入到Unity或其他引擎里面进行Final PBR Rendering，进行最终的渲染。

那么，ArtEngine的工作流程是怎么样的呢？简单来说，ArtEngine就是将DATA进行AUTOMATION自动化。

DATA的来源包含SEARCH、SCAN、PAINT三部分。SEARCH就是我们可以从网上搜到想要的贴图进行转换；SCAN就是扫描，包括拍照；PAINT是你可以直接画材质贴图，再利用ArtEngine强大的AI功能进行二次加工。

然后，ArtEngine处理的是AUTOMATION自动化的流程，将DATA进行增强（ENHANCE），把它扩展到别的功能（EXPAND），再转换（TRANSMUTE）一下。

首先看一下Enhance增强，我们可以用来提高扫描和旧素材的质量。

首先是提高分辨率Up Resolution，更新并回收旧的、弃用的内容，使其成为新内容。低分辨率图像使用ArtEngine的神经网络，能提高图像的原始分辨率而不降低质量。

可以看下面这张贴图，本身512的时候你可以看到它的画面质量是比较低的，已经像素化了，这个时候通过ArtEngine的解决方案转化成2048×2048的贴图，它的细节会被机器学习的神经网络进行自动补充。

接下来我们看看这是怎么操作的：首先创建一个节点把它连上去，在Evaluate这个节点就可以看到，通过机器学习的强大功能，它自动把细节进行了补充，提升了分辨率。

接下来我们再看JPEG压缩还原。

大家知道如果我们没有专业设备，如数码相机单反等，那我们可能会使用iPhone拍摄。iPhone默认并不会存Raw的原始图像，而是会导成JPEG格式，JPEG的图像是经过了有损压缩的，这导致我们的图像可能有一些瑕疵，这就是ArtEngine发挥作用的时候了。即便在源文件丢失的情况下，ArtEngine也可以使用人工智能轻松还原JPEG压缩后的图像，从而以原始图像质量重新创建丢失的图像。

可以看到这边这张图其实是有一些噪点的，这是压缩导致的一些瑕疵，右边这张ArtEngine处理过的图，可以看到它是很柔滑的。

所以，通过ArtEngine，你可以修复一些JPEG压缩的瑕疵。我们来看一下怎么操作的。同样，我们需要创建一个节点进行连接，通过放大可以看到有一些因为压缩产生的瑕疵，我们Evaluate一下这个节点，可以看到瑕疵就被修复了。

接下来我们再看Expand扩展。扩展是什么呢？就是充分利用现有的资源将现实世界的丰富性和多样性带入数字领域，扩大你的创作力。

首先我们来看接缝消除。接缝消除就可以一次擦除所有PBR贴图中的材质接缝，以快速清理材质并去除不需要的部分，也就是说我们常说的把贴图变成循环贴图。

接下来看一下接缝消除是怎么操作的。我们选择所有贴图，然后把它转换成material，然后连接Seam Removal节点，选择你要Tiling的范围，同样的Evaluate一下这个节点，你可以看到一个可循环贴图创建完成了。

接下来我们看变化Mutation。通过允许 AI 仅基于一种输入想象看似无穷无尽的可能性，为您创建的环境带来更多的多样性和生命力，并使纹理库增加四倍。

首先我们看一下通过AI的Mutation和通过程序化的Randomizer有什么区别。

可以看到左边这张贴图是我们通过AI进行Mutation以后创建的贴图，它是没有任何瑕疵的。但是右边通过程序化Procedural来生成的图，你会发现它其实是把原贴图进行随机缩放、摆放、旋转，再变成一张新的贴图，如果不经过调整就会有蓝圈里面的瑕疵。

接下来我们看转换Transmute。Transmute就是针对特定用途进行调整，来更改资源的性质或特征。让不足或有缺陷的资源变得满足需求且易于使用。

首先我们来看第一个Transmute，颜色转换（Color Match）。我们从一幅图像中获取颜色信息，并将其转移到另一幅图像的结果中，以快速实现外观开发迭代。

我们来看一下怎么操作Color Match。我们准备两张贴图创建一个Color Match的节点，把它们连在一起，然后Evaluate一下，可以看到它就会把原贴图变成target贴图的色系。所以当你要处理一个很大的场景，有不一样的贴图的时候，你可以通过这种转换来生成不一样的色系，让它协调。

好，接下来我们看看颜色转换。颜色转换还是Color Match，但是我们Color Match还有别的用途，比如说法线贴图强度转换。

因为我们在用法线的时候可能会有一些比较强的法线，以及有一些比较弱的法线，这个时候我们需要把他们整合成比较一致的强度，让场景更加协调。

同样的，我们还能进行粗糙度转移。把它的Roughness转换成想要的目标Roughness。比如这张是原图，这个是参考的。通过参考的进行转换以后就会获得跟目标一样的Roughness，也会让场景更加协调。

接下来我们看图案展平Pattern Unwarping。通过自动检测并展平图案以对齐图像空间中的任何常规纹理图案，自动减轻处理皱纹和拉伸等变形纹理的工作量。

可以看到左边这张布料其实是被拉伸变形的，但是我们可以通过Pattern Unwarping把它转换成一个非常标准的常规的纹理图案。

接下来我们看一下怎么操作。同样，我们需要创建一个Pattern Unwarping的节点，然后选择一个单位的Pattern，进行转换，然后就可以获得一个非常好的效果。

接下来我们再来看一下内容感知填充。我们在大自然采集到的贴图可能是会有一些瑕疵的，比如这个草地中就有一些落叶，我们需要选取它们进行移除。常规的做法可能就是拿到Photoshop里面用印章功能来去除，但是通过我们ArtEngine就没有这么复杂。只要简单地选择你想要去除的地方，运行一下，它就会自动去除并填充内容。

同样我们来对比一下AI和程序化的区别。图片中红框里都有瑕疵，通过AI处理的图片，你可以看到被补充的内容是不会有红框的，AI会知道这个地方不应该出现红框。但是程序化的软件就不会有这个“意识”，即便我们把采点已经选择在一个没有有红框的地方，但是它被采集的时候还是自动补了红框。

这张图是我用来测试的，红框内有瑕疵。你可能想正常的贴图不可能有红框，但是如果你要处理一个门、一扇窗，它们都是有框的。这个时候，如果门上有些瑕疵你想修复，程序化的软件会错误地采集到门框上的信息进行修复，那就会很麻烦。

我们来看一下这个是怎么操作的。我们首先选择要去除的地方，生成一个Mask，通过Content Aware Fill就可以进行填充。可以看到直接就去除了落叶，非常简单。

我们的贴图就制作得差不多了，接下来要输出出去。下面就是PBR输出（Export）。最终材质的数据为PBR贴图，无缝地与Unity衔接，进行最终渲染。

通过PBR材质生成，将单张照片或烘焙的扫描结果转换为完整的高质量PBR材质，以取得行业领先的结果。可以看到，通过转换以后，我们有法线，有高度图进行Tessellation以后就是一个非常高质量的PBR材质。

接下来我们拿一个真实的案例看一下是怎么操作的。

我们有一张原贴图，可以看到放大以后它的分辨率是不够的，我们通过Up Resolution节点提升分辨率，再通过Content Aware Fill去除瑕疵，可以看到黑缝就去除了。

它并不是个Tiling可循环的贴图，这个时候我们再去掉接缝Seam Removal。

接下来我们通过Mutation变化来让它变成随机的贴图，看起来没有那么千篇一律。再来看一下原始贴图，然后通过转换以后是不是非常完美了？最后我们通过生成法线贴图，高度贴图，这个Compose Material就是我们最后的材质。可以看到它有一些法线的凹凸。

这里我们还演示了一下通过Color Match转换成某一个色系。比如这个就是转换以后的，你甚至可以把这张贴图用在雪地中。我们还是预览回原来这张贴图。

最后，我们是要进行导出，通过Export to Unity可以导出到Unity中。或者我们可以通过Output节点导出输出的贴图。

我们到Unity里面用ArtEngine的插件进行导入。我们把它放上去。可以把ArtEngine里面的贴图还原到Unity当中去。通过Output节点进行输出贴图，可以用于别的地方，而不仅仅是Unity。

选择我们想要的通道，还有些参数可以设置，比如保存到哪里。

那使用ArtEngine有什么好处呢？

首先可以降低使用门槛，AI赋能不需要或者需要较少的专业美术人员进行调参，比程序化生成类工具更加易用，不需要强大的数学基础。同时更灵活，节点式比图层式有更大的发挥空间。其次，还能降低成本，摄影制图流程，节约了素材制作的成本，它不需要专业的设备采集，无缝衔接PBR工作流程。

同样，它可以给你的游戏带来更高的品质，因为它可以快速地提高素材的质量，AI可以填补程序化生成的不足。

接下来我们看看Unity收购的另外一个新产品Plastic SCM。

Plastic SCM是专注于游戏开发的版本管理系统。Plastic SCM针对游戏开发设计，更好地支持大二进制文件，针对美术、策划，它简化了UI和工作流；针对程序，它能够像Git一样支持更好的分支，基于语义的合并，更加完善的权限管理和更高的性能。

好，我们来跟市场上常用的一些版本管理工具进行一些对比。比较常用的是Git、SVN，还有商业化的Perforce，我们Plastic SCM对比下来是完全占优的。

首先我们看灵活性，各种各样的人员都可以使用这款产品。比如像策划和美术他们肯定是比较喜欢SVN或者是Perforce那样Centralized中心化的管理。Just check in，no  push/pull。check in就相当于Git里面的commit，就是只需要commit，不需要push或者是pull那么麻烦。像SVN的话只要commit就直接到服务器上了。这个就是策划和美术比较喜欢的流程，因为他们比较喜欢简单，不会操作错误的一个工作流。

而对于程序来说，他们肯定会喜欢像Git的操作方式，就像Good to work distributed，就是一个分布式，然后本地有一个版本管理，我写错代码可以随时回滚，随时开不一样的分支来进行测试。所以，Plastic SCM是兼顾了SVN或者是Perfore，或者是Git的所有优点，它既能中心化地管理你的版本，也可以分布式地管理。

其次，我们看对大文件、二进制文件的处理。对于一个hugerepos一个大的库来说，Perforce有更加好的支持，但是SVN并不是特别好。对于Git来说就更加不用说了，因为Git对二进制支持还需要Git LFS Extension来处理。但是，Plastic SCM天生就对二进制文件有很好的支持。所以，它会Good with huge repos，good with huge files。对于大文件，SVN有些时候也是有点吃力的，对于Perforce倒是比较好。所以Plastic SCM融合了SVN、Git、Perforce的优势，对二进制有一个很好的支持。

大家也知道对于美术和策划来说通常操作的东西都是一些二进制文件，比如PSD、JPG、PNG这些贴图，对于美术来说还有一些视频，对于策划来说还有一些文档，像docx，它通常是binary二进制的东西。这个时候，它并不会像程序一样两边协同一起开发，你写你的代码，我写我的代码，最后进行合并。这个时候对于美术和策划来说他们可能需要一个locking，Plastic SCM就提供了这个功能，can lock files to avoid merging，意思是当我要修改这个二进制文件之前，我先把它锁了，锁了以后就可以避免之后产生冲突的合并。

我们再来看GUI。GUI就是界面。我们可以Visualize Your Repos可视化你的版本库。这里还说So you don’t needa PHD in brauning。因为对于这个分支来说，对于程序来说都比较复杂，但是对于美术和策划来说更加难以理解。所以，通过一个可视化的Visuallizes your repos，通过Branch Explorer你可以看到一个可视化的版本库。

Come with great GUIs，可以看到Plastic SCM也是完胜的。对于Perforce来说它是个商业产品，所以它本身有一个不错的UI，但是SVN和Git的原生并没有一个好的UI，SVN和Git里面可能还需要Tortoise小乌龟或者是Git Extension等等这些插件来辅助管理。

其次，我们Plastic SCM还有一个Special GUI & workflow forartists。我们有一个Gluon的界面，它非常简单，只有三个页签，所以，它会大大地简化美术和策划的使用流程，降低他们的使用难度。

And anyone not a coder，就是说不是程序也是能够好好地掌握的。

接下来我们看Workflow工作流，Plastic SCM我前面所说的它融合了Git、Perforce和SVN好处。其实像Perforce、SVN没有一个真正很好的分支，他们的分支都是拷贝，它并不会记录Changeset修改。所以大家进行分支以后合并是很痛苦的操作。Git是可以，但是进行分支处理的时候还是需要一些第三方的GUI可视化的工具来更好地做这个Branch分支，而Plastic SCM原生自带。

接下来我们看Merge。Plastic SCM和Git一样都可以very good delecting merges between branches，就像前面说的Git是有真分支的，Plastic SCM也是有真分支，它可以很好地利用分支changeset记录的修改来很好地自动化合并。

Plastic SCM还提供了很好的差异化和三方合并工具。像Git、SVN还可能需要像Kdiff工具，但是我们Plastic SCM自带。而且我们还自带一个很强大的Semantic Merge的工具，它是可以基于语义的合并或者基于语义的Diff，非常强大，它能读懂你的代码，可以很好地去Merge你的代码，它能知道你这是一个类，是一个方法，你这个方法可能重构以后进行了挪动，它也知道它是属于这个类里面的方法，所以它进行重构的时候不会像基于文本的合并一样，你挪了位置，它就以为你这里可能产生冲突，但是你这里挪了位置，同时另外一个人也修改了里面的内容，它也能自动合并。

Toolshelp you understand a merge (a preview)，我们可以进行预览。对于Plastic SCM来说是自带的，对于GIt或者是Perforce、SVN来说是没有这个功能的。

我们再来看，Good merging renames，moviedfiles，directories为，crazy refactors。大家都知道像程序在写代码为了优化它的可读性的时候肯定一直都会进行重构，重构以后就会有合并，需要我们Rename改名字或者是移动文件目录，甚至像我前面所说的，在重构的时候挪动代码位置，这些操作都是很正常的。但是，在Git、SVN和Perforce里面都是没有一个很好的处理的。只有我们Plastic SCM能处理这个事情。

接下来看云端。大家也知道在中国大多数公司并不会使用云端，但是在国外很多公司会使用云端。或者是有一些在中国，但是外资的开发商也会使用云端。所以，我们也提供了云端的服务。Plastic SCM Cloud就类似于Git里面的Git Lab、Git Hub、Bit Bucket这种。那我们Plastic SCM是有提供的。

Cloudhosting is good with huge repos，就是我们前面所说的大的版本库，只有我们Plastic SCM可以很好地处理。

接下来看Diff，像前面所说的Merge是合并，Diff是来看那些代码的差异。Can diff code moved across files哪怕你这些代码从另外一个文件挪到这个文件，它也可以产生差异化的浏览。

Can show you the history of a method,可以给你看到这个Method的修改记录。

还有最后的一点You canreach the engineers，你可以很好地接触到我们的工程师。大家也知道Plastic SCM这个Codice的公司已经被Unity收购了。Unity在大中华区是有办公地点的，总部在上海，北京有分公司，广州有办公室。所以，当你遇到需要解决的问题，你可以联系到我们的工程师，但是对于Git来说大家也知道Git的作者是Linux，你能找得到Linus吗？不大可能。Perforce是个商业产品，可能还能找得到。SVN就不用说了，跟Git类似的情况，你很难找到开发者去反馈问题，解决问题。

Plastic SCM功能是非常强大，那强大的功能如果是一个比较差的性能，这个版本管理控制系统也是不能使用的。我们来看一下。

Plastic SCM的性能。首先看它的网络性能。大家知道一般像Git、SVN、Perforce都是用TCP协议进行传输的，但是我们Plastic SCM是可以用UDT的特殊协议，就是UDT的传输协议，UDP Transmission是一个可靠的UDT协议。通过TCP协议在内网环境你可以看到512兆也需要200多秒，在公网它是100兆，但是有100毫秒的延迟，甚至可能还有丢包的情况，它只需要97秒。

类似的2GB在TCP的时候是900秒，但是在UDT的时候只有390多秒。大家知道丢包的时候TCP是从头开始重发，但是对于UDT来说，它只有丢哪个包重发哪个包，它解决丢包的协议显然更优。

网络性能是没有问题的。那我们实际上使用的性能又是怎么样的？首先我们看一个例子，一个Small Repo小型的版本库，它有6万多个文件，700多兆。这个时候你会发现Add、Checkin就像Git里面的stage+commit，你可以看到Plastic SCM对于Perforce来说有8倍的性能提升。对于Git来说有5.7倍的性能提升。那大家可以看到在使用中是很有优势的。

提交可能只是程序、美术、策划需要做的，但是拉取代码其实是每个人都要做的。提交的操作可能只是进行修改的人需要做，但是拉取的操作，则需要拉取每个人在协同操作中的操作。那这个时候Update的性能就显得尤为重要，因为节省的是整个项目组所有人的时间。

比如说看这里，Update，拉一个版本库如果像Perforce要56秒的话，Plastic SCM只要22秒表，Git需要30秒，它是有1点多倍的提升。

接下来看一个中型的版本库。它有18万个文件，7.16 GB。这个时候我们可以简单地看，像Plastic SCM本身就对于Perforce有5.2倍的提升，对于Git来说有5.3倍的提升。如果只有提交的那个人需要做这个操作，那这个省下来的并不是特别明显，最明显的是每个人都要做的Update，每个人都要拉取的，那这个时候你发现Plastic SCM是非常有优势的，哪怕对比Git，它只有不到一半的时间，对比Perforce也是不到一半的时间，省的是整个团队所有人协作开发的时间，有助于提高整个团队的工作效率。是不是非常强大？

好，前面一直在提Semantic Merge，基于语义的合并。那到底什么是Semantic Merge呢？大家可以看到像这里一个Socket 把它挪到ServerSocket时发生了重构，这个时候你看它还能读懂我们这里做的操作是把Socket Recv为两个类，一个叫ServerSocket，一个叫ClientSocket。我们把Listen和Recv方法挪到ServerSocket里面。

所以可以看到在这里我们把这个方法HashToTex挪到了一个内部类Hasher里面去，它同样是可以识别到我们是基于类的合并。

同样的这个它哪怕前后挪动了位置进行了修改，它也能很好地识别这种重构，进行合并。

类似的也是一样，也是有先后的挪动，并且修改了里面的东西。而且它主要是挪动到了一个新的Dns类里面，它哪怕挪到另外一个类里面都能够被好好地识别出来。

好，这个就是我们提交的时候合并的所有可视化，可以更好地看明白它是怎么被修改的。

同样的，当我们发生一个Semantic Merge提交的时候，就是基于语义的合并提交，你可以看到它是怎么进行Merge的。

这个就是前面所说的例子，把Socket都已经转换成ClientSocket类了，它还能认识，它是跨文件的，就像它有个Socket，一个ServerSocket，它同样能够自动处理这个合并。

我们还能Semantic Method History直接看到某个方法的历史记录，是不是非常强大？

好，Plastic SCM这个强大的针对游戏开发的版本管理系统已经介绍完了，接下来介绍我们今天最后的一款产品，Backtrace，跨平台异常崩溃信息收集平台。

Backtrace可以跨全平台收集异常的崩溃信息。无论你的客户端用是的Unity还是其他引擎、服务端用的是Java、C/C++，还是TypeScript（Node.js）都可以收集，它有丰富的SDK进行集成，拥有更丰富运行环境信息，拥有更全面的筛选分类信息。

我们来看这里一个测试的项目，这是我自己编的一个项目，有一个TestProject，点一下Exception，它就会提供一个Managed Exception托管的异常，再点一下Crash，让它整个崩溃掉。这里是我捕捉到的情况。可以看到对于Managed Exception，它就会告诉你这是一个Exception，对于崩溃它就会告诉你是一个Breakpoint断点，你就可以更好地筛选处理你的崩溃信息。

这里举个例子，我们打开了一个Exception，其实你可以看到我自己写的一个TestException的方法，这里你还能看到当时的日志，甚至还能看到当时的运行情况，比如这个应用的名字就叫做TestBacktrace，它的Company是Default Company，它是不是一个Debug包？不是，是不是在Editor里面？并不是。还有像当时的场景叫Sample Scene，它的Sample Scene是第几个，它都是有这些信息的。

看完Managed Exception托管的异常，我们再看一下崩溃。

可以看到你并不需要自己去上传符号表，因为它跟Unity是深度整合的，所以它能自动获取Unity的符号表。像这里所有的函数签名都是有的，不需要手动上传或转换。可以获得最准确的堆栈信息，还能看到所有线程当时是怎样的情况。

好，接下来我们看一下其他的崩溃信息捕捉平台。可以看到同样是TestException，你会发现它捕捉到的信息是并没有Backtrace多的，它的堆栈信息也不是特别完整。

再来看崩溃这里，就更加奇怪了。我通过Force Crash用Unity原生的接口让它崩溃。你可以看到在Backtrace可以捕捉到Native Crash的堆栈，但是其他的崩溃收集平台，就只能收集到Manage Exception那一部分的崩溃或者是Unity Log Error这块的堆栈，并不能收集到当时Native Crash的堆栈信息。

所以我们这个Backtrace还是非常强大的。

我们再来直接打开Backtrace后台的Console给大家看一下。大家可以看到这是一个Backtrace的Console，我们展开一个崩溃或者是错误，就可以看到当时的TestException，这是一个Managed Exception。如前面所说的它会提供很丰富的环境信息，像这里会有Process Age已经运行了多久，还有当时系统的Memory内存的情况。大家也知道很多崩溃可能只会在低内存的时候浮现，如果能有丰富的内存信息，我们在复现这个崩溃并进行修复的时候就会有更多的线索和思路。

类似的，它还能知道你当时运行的版本是Unity的哪个版本，它的CPU用的是ARM64还是X86的Android，内存这里你还可以看到正在用的（Active），空闲的内存（Free），还有虚拟的内存（Swap）是多少，等等，让你更好地处理这个崩溃，去查找更多线索。还有当时的系统语言，因为很多时候，特别是像东南亚越南系的这些语言有些时候会有些奇怪的异常、错误和崩溃是由于小语种引起的，所以知道系统的语言也是非常重要的。同样，它还能知道是否是因为CPU的温度过热导致崩溃。

还有Manufacturer运行环境的生产商。比如这是一个安卓手机，那它的生产商是小米，当时测试的这台是小米的红米K30 Pro，它用的是高通Qualcomm的芯片，等等这种信息。还能看到它当时的Graphics，我们去做一个兼容性非常好的游戏可能会用Vulkan，用OpenGL ES这些东西，但是有些问题复现的时候可能会在OpenGL ES里浮现，有些问题可能会在Vulkan里面浮现。知道当时的Graphic Type也是个很重要的线索。就像这样，可以提供更多的线索让我们去处理崩溃信息等等。

同样我们可以再看另一个Unity Demo。看这个信息，大家都知道像其他一些崩溃捕捉信息的平台可能只能兼容Android、iOS，我们的Backtrace还可以兼容PS4这样的平台。而且，Backtrace不是仅限于使用Unity，其他引擎也可以使用。

好，今天给大家分享的就到这里，就是我们Unity新的三个产品，可以帮助开发者更加好地去开发Unity的游戏或者是别的游戏。谢谢大家。