本文目录一览：
- 1、如何用Cocos引擎打造次世代3D画质‘游戏大观
- 2、cocoscreator和cocoscreator3d的区别
- 3、cocos3d里怎么点中一个3d模型对象
- 4、Cocos 3.x 由浅到浅入门批量渲染
- 5、Cocos 3.x camera
如何用Cocos引擎打造次世代3D画质‘游戏大观
1. 光照贴图（Light Mapping）：你将看到每件物体都有被照亮并且投射阴影。光影效果的质量是由你的3D工具软件决定的，用3D软件能烘焙出复杂的光效，包括直接光照，反射光照，以及阴影。
2. 顶点合并（Vertex Blending）：请注意看路、草地和悬崖交接的地方，看不到任何可见的接缝。
3. 透明遮罩（Alpha Masks）：灌木如果没有透明遮罩就跟纸片一样。
4. 滤色叠加的公告板（Billboards）：增加一些光束和其他环境的效果。
cocoscreator和cocoscreator3d的区别
CocosCreator3D轻量、易用的跨平台3D游戏创作工具。目前CocosCreator最新版同时支持2D和3D游戏开发。
CocosCreator3D是在CocosCreator基础之上全面升级而来的纯3D游戏编辑器产品。
秉承着Cocos一贯的低成本，低门槛，高性能，跨平台等产品特性。这款全新的一体化3D游戏编辑器旨在成为开发者创作3D游戏的新选择。
适合中小规模3D游戏团队以及资源有限的独立团队，希望自己的游戏跨原生、Web、小游戏等平台。快速上手
cocos3d里怎么点中一个3d模型对象
触摸坐标是否在精灵上第一个思路是先获取你的sprite的boundingBox,和你触摸点坐标，判断触摸点坐标是否包含于sprite的区域内(这个rect是包含sprite的位置横纵坐标和宽高)
CGRectContainsPoint(你的精灵的RECT,你触摸的点的坐标)
获取精灵的方法可以考虑将你的所有精灵加入到一个单例层里作为精灵管理层，加进去的时候定义好TAG值，方便随时随地可根据TAG值取到你想要的精灵。
Cocos 3.x 由浅到浅入门批量渲染
参考
由浅到浅入门批量渲染（一）
由浅到浅入门批量渲染（二）
由浅到浅入门批量渲染（三）
由浅到浅入门批量渲染（四）
由浅到浅入门批量渲染（完）
【Unity游戏开发】静态、动态合批与GPU Instancing
本文只摘抄部分原文，达到概念性了解。
批量渲染其实是个老生常谈的话题，它的另一个名字叫做“合批”。在日常开发中，通常说到优化、提高帧率时，总是会提到它。
可以简单的理解为： 批量渲染是通过减少CPU向GPU发送渲染命令（DrawCall）的次数，以及减少GPU切换渲染状态的次数，尽量让GPU一次多做一些事情，来提升逻辑线和渲染线的整体效率。 但这是建立在GPU相对空闲，而CPU把更多的时间都耗费在渲染命令的提交上时，才有意义。
如果瓶颈在GPU，比如GPU性能偏差，或片段着色器过于复杂等，那么没准适当减少批处理，反而能达到优化的效果。所以要做性能优化，还是应该先定位瓶颈到底在哪儿，然后再考虑优化方案，而不是一股脑的就啪啪啪合批。当然，通常情况下，确实是以CPU出现瓶颈更为常见，所以适当的了解些批量渲染的技法，是有那么一丢丢必要的。
静态合批是一种听起来很常用，但在大多数手游项目里又没那么常用的合批技术。这里，我简单的将静态合批分为预处理阶段的合并，和运行阶段的批处理。
合并时，引擎将符合合批条件的渲染器身上的网格取出，对网格上的顶点进行空间变换，变换到合并根节点的坐标系下后，再合并成一个新的网格；这里需要注意的是，新网格是以若干个子网格的形式组合而成的，因为需要记录每一个合并前网格的索引数量和起始索引（相对于合并后的新网格）。
空间变换的目的，是为了“固化”顶点缓冲区和索引缓冲区内的数据，使其顶点位置等信息都在相同的坐标系下。这样运行时如果需要对合并后的对象进行空间变换（手动静态合批对象的根节点可被空间变换），则无需修改缓冲区内的顶点属性，只提供根节点的变换矩阵即可。
在Unity中，可以通过勾选静态批处理标记，让引擎在打包时自动合并；当然，也可以在运行时调用合并函数，手动合并。打包时的自动合并会膨胀场景文件，会在一定程度上影响场景的加载时间。此外，不同平台对于合并是有顶点和索引数量限制的，超过此限制则会合并成多个新网格。
运行时是否可以合批（Batch）成功，还取决于渲染器材质的设置。
当然，如果手动替换过场景中所有Material，也会打断批次。
静态合批与直接使用大网格（是指直接制作而成，非静态合并产生的网格）的不同，主要体现在两方面。
其一，静态合批可以主动隐藏部分对象。静态合批在运行时，由于每个参与合并的对象可以通过起始索引等彼此区分，因此可以通过上述多次DrawCall的策略，实现隐藏指定的对象；而直接使用大网格，则无法做到这一点。
其二，静态合批可以有效参与CPU的视锥剔除。当有剔除发生时，被送进渲染管线的顶点数量就会减少（通过参数控制），也就意味着被顶点着色器处理的顶点会减少，提升了GPU的效率；而使用大网格渲染时，由于整个网格都会被送进渲染管线，因此每一个顶点都需要被顶点着色器处理，如果摄像机只能照到一点点，那么绝大多数参与计算的顶点最后都会被裁减掉，有一些浪费。
当然，这并不意味着静态合批一定就比使用大网格要更好。如果子网格数量非常多，视锥剔除时CPU的压力也会增加，所以具体情况具体分析吧~
静态合批采用了以空间换时间的策略来提升渲染效率。
其优势在于：网格通常在预处理阶段（打包）时合并，运行时顶点、索引信息也不会发生变化，所以无需CPU消耗算力维护；若采用相同的材质，则以一次渲染命令，便可以同时渲染出多个本来相对独立的物体，减少了DrawCall的次数。
在渲染前，可以先进行视锥体剔除，减少了顶点着色器对不可见顶点的处理次数，提高了GPU的效率。
其弊端在于：合批后的网格会常驻内存，在有些场景下可能并不适用。比如森林中的每一棵树的网格都相同，如果对它采用静态合批策略，合批后的网格基本等同于：单颗树网格 x 树的数量，这对内存的消耗可能就十分巨大了。
总而言之，静态合批在解决场景中材质基本相同、网格不同、且自始至终都保持静止的物体上时，很适用。
试想一个场景：一场激烈的战斗中，双方射出的箭矢飞行在空中，数量很多，材质也相同；但因为都在运动状态，所以无法进行静态合批；倘若一个一个的绘制这些箭矢，则会产生非常多次绘制命令的调用。
对于这些模型简单、材质相同、但处在运动状态下的物体，有没有适合的批处理策略呢？有吧，动态合批就是为了解决这样的问题。
动态合批没有像静态合批打包时的预处理阶段，它只会在程序运行时发生。 动态合批会在每次绘制前，先将可以合批的对象整理在一起（Unity中由引擎自动完成），然后将这些单位的网格信息进行“合并”，接着仅向GPU发送一次绘制命令，就可以完成它们整体的绘制。
动态合批比较简单，但有两点仍然需要注意：
动态合批不会在绘制前创建新的网格，它只是将可以参与合批单位的顶点属性，连续填充到一块顶点和索引缓冲区中，让GPU认为它们是一个整体。
在Unity中，引擎已自动为每种可以动态合批的渲染器分配了其类型公用的顶点和索引缓冲区，所以动态合批不会频繁的创建顶点和索引缓冲区。
在向顶点和索引缓冲区内填充数据前，引擎会处理被合批网格的每个顶点信息，将其空间变换到世界坐标系下。
这是因为这些对象可能都不属于相同的父节点，因此无法对其进行统一的空间转换（本地到世界），需要在送进渲染管线前将每个顶点的坐标转换为世界坐标系下的坐标（所以Unity中，合并后对象的顶点着色器内被传入的M矩阵，都是单位矩阵）。
相对于上述看起来有点厉害但是本质上无用的知识而言，了解动态合批规则其实更为重要。比如：
当我们想要呈现这样的场景：一片茂密的森林、广阔的草原或崎岖的山路时，会发现在这些场景中存在大量重复性元素：树木、草和岩石。它们都使用了相同的模型，或者模型的种类很少，比如：树可能只有几种；但为了做出差异化，它们的颜色略有不同，高低参差不齐，当然位置也各不相同。
使用静态合批来处理它们（假设它们都没有动画），是不合适的。因为数量太多（林子大了，多少树都有）， 所以合并后的网格体积可能非常大，这会引起内存的增加 ；而且，这个合并后的网格还是由大量重复网格组成的，不划算。
使用动态合批来处理他们，虽然不会“合并”网格，但是仍然需要在渲染前遍历所有顶点，进行空间变换的操作；虽然单颗树、石头的顶点数量可能不多，但由于 数量很多，所以也会在一定程度上增加CPU性能的开销，没必要 。
那么，对于场景中这些模型重复、数量多的渲染需求，有没有适合的批处理策略呢？有吧，实例化渲染就是为了解决这样的问题。
实例化渲染，是通过调用“特殊”的渲染接口，由GPU完成的“批处理”。
它与传统的渲染方式相比，最大的差别在于：调用渲染命令时需要告知GPU这次渲染的次数（绘制N个）。当GPU接到这个命令时，就会连续绘制N个物体到我们的屏幕上，其效率远高于连续调用N次传统渲染命令的和（一次绘制一个）。
举个例子，假设希望在屏幕上绘制出两个颜色、位置均不同的箱子。如果使用传统的渲染，则需要调用两次渲染命令（DrawCall = 2），分别为：画一个红箱子 和 画一个绿箱子。
如果使用实例化渲染，则只需要调用一次渲染命令（DrawCall = 1），并且附带一个参数2（表示绘制两个）即可。
当然，如果只是这样，那GPU就会把两个箱子画在相同的位置上。所以我们还需要告诉GPU两个箱子各自的位置（其实是转换矩阵）以及颜色。
这个位置和颜色我们会按照数组的方式传递给GPU，大概这个样子吧：
那接下来GPU在进行渲染时，就会在渲染每一个箱子的时候，根据当前箱子的索引（第几个），拿到正确的属性（位置、颜色）来进行绘制了。
静、动态合批实质上是将可以合批的对象真正的合并成一个大物体后，再通知GPU进行渲染，也就是其顶点索引缓冲区中必须包含全部参与合批对象的顶点信息； 因此，可以认为是CPU完成的批处理。
实例化渲染是对网格信息的重复利用，无论最终要渲染出几个单位，其顶点和索引缓冲区内都只有一份数据， 可以认为是GPU完成的批处理 。
其实这么总结也有点问题，本质上讲： 动、静态合批解决的是合批问题，也就是先有大量存在的单位，再通过一些手段合并成为批次；而实例化渲染其实是个复制的事儿，是从少量复制为大量，只是利用了它“可以通过传入属性实现差异化”的特点，在某些条件下达到了与合批相同的效果。
无论是静态合批、动态合批或实例化渲染，本质上并无孰优孰劣，它们都只是提高渲染效率的解决方案，也都有自己适合的场景或擅长解决的问题。个人以为：
Unity下可以通过以下两种方式快速优化骨骼蒙皮动画：
在相同的测试环境下，再次进行测试后可以发现，这种方法确实可以产生一定效果。其原因我认为主要有以下两点：
开启GPU蒙皮，Unity会通过ComputeShader的方式，使用GPU进行蒙皮。GPU上有大量的ALU（算数逻辑单元），可以并行大量的数值计算，效率较高，应该很适合这种针对顶点属性的数值计算。
但是实际情况是：在移动设备上使用GPU蒙皮反而会使主线程的耗时增加。通过Profiler可以发现，CPU把更多的时间放在了执行ComputeShader上，由于骨骼动画的实例很多（500个），所以这个调用时间本身成为了性能热点。所以，以目前的情况来看，这种在移动设备上使用GPU蒙皮的方式，似乎不适合处理大量骨骼蒙皮动画实例（也许是我使用的方式存在问题）。
简单来说，它们基本的思路，都是将骨骼蒙皮动画的“结果”预先保存在一张纹理中；然后在运行时通过GPU从这张纹理中采样，并使用采样结果来更新顶点属性； 再结合实例化技术（GPU instancing） ，达到高效、大批量渲染的目的。
可以简单的将它的工作流程分为两个阶段：
这个阶段其实是为后面的播放阶段准备动画资源，你也可以把这个资源简单的理解为一种特殊类型的动画文件。
首先，在编辑状态下，让携带骨骼蒙皮动画的角色，按照一定帧率播放动画。我们知道：动画播放时，角色网格会被蒙皮网格渲染器（SkinnedMeshRenderer）更新而产生变形（顶点变化）；如果在动画播放的同时，记录下每一个顶点在这一时刻相对于角色坐标系（通常是角色脚下）的位置。那么，当动画播放完毕时，我们会得到一张“每一个顶点在每一个关键帧时的位置表”，我们就叫它“帧顶点位置表”吧。可是“帧顶点位置表”名字太长，你可能不太好记，我打字也比较麻烦，所以我们后面就叫它“表表”吧。
除了表表，我们还能得到与它对应的动画信息，比如这个动画的名称、时长、帧率、总帧数、是否需要循环播放等信息。
到这里，第一个阶段我们需要的内容就准备就绪了，可以进入下一个阶段：播放动画阶段。
在动画播放时，通过一个变量（播放时长）来更新播放进度；结合上一阶段我们记录下来的动画总长度、动画总帧数信息，就可以计算出当前动画播放到了第几帧（当前帧数 = 已播放时长 / 动画总时长 x 动画总帧数）。一旦得到当前动画帧，就表示可以通过表表锁定一行顶点数据。
接下来，只要遍历这行顶点数据；然后根据索引找到网格中对应的顶点并更新它的位置，就等于完成了蒙皮工作。
既然通过一个播放进度、表表和一些简单的动画信息，就能直接完成蒙皮（对顶点属性的更新），那么我们就不再需要以下内容了：
使用CPU来读取表表，并遍历更新所有顶点，显然不如GPU来的高效；所以接下来，我们将这一步放到渲染管线中的顶点变换阶段，借着GPU处理顶点的契机，完成使用表表中的数据对顶点属性进行更新。
实例化渲染的特点是使用相同网格，相同材质，通过不同的实例属性完成大批量的带有一定差异性的渲染；而烘焙顶点恰好符合了实例化渲染的使用需求。
所以，我们只需将控制动画播放的关键属性：比如过渡动画播放的V坐标、当前和下一个动画的插值比例等，放入实例化数据数组中进行传递；再在顶点着色器中，对关键属性获取并使用即可。
与蒙皮网格渲染器的比较
烘焙顶点的主要问题
除了烘焙顶点，另一种常用的优化方案是烘焙骨骼矩阵动画。
听名字就知道，烘焙骨骼矩阵与烘焙顶点位置，原理十分相似；最大的差异在于它们在烘焙时所记录的内容不一样：烘焙顶点记录下来的是每个顶点的位置，而烘焙骨骼矩阵记录下来的是每一根骨骼的矩阵，仅此而已。
烘焙骨骼矩阵最大的意义在于它补上了烘焙顶点的短板：受顶点数量限制、烘焙的动画纹理过大 及 纹理数量较多。
烘焙顶点对于纹理（面积）的使用是受顶点数量决定的，可以简单理解为：
所以，当模型的顶点数量过多时（数以千计），这种烘焙方式或者无法烘焙下整个模型（顶点数量2048），或者需要一张或多张（法线、切线）大尺寸纹理（2048 1024）。
但是，烘焙骨骼矩阵主要取决于骨骼的数量，可以简单理解为：
在移动平台上，通常20根左右的骨骼就可以取得不错的表现效果，所以相对于烘焙顶点，烘焙骨骼可以记录下更长的动画，同时它也不再受顶点数量的限制，也无需对法线或切线进行特殊处理（因为可以在采样后通过矩阵计算得出）。
针对这两种方案，我个人认为并没有绝对的孰优孰劣；正如你所看到的，烘焙骨骼在处理复杂模型或多动作时更具优势；但如果渲染数量较多、模型顶点数较少、表现需求较弱（无需法向量参与计算）时，烘焙顶点也是值得尝试的，因为它在性能上会更好一些。
目前静态合批方案为运行时静态合批，通过调用 BatchingUtility.batchStaticModel 可进行静态合批。
该函数接收一个节点，然后将该节点下的所有 MeshRenderer 里的 Mesh 合并成一个，并将其挂到另一个节点下。
在合批后，将无法改变原有的 MeshRenderer 的 transform，但可以改变合批后的根节点的 transform。只有满足以下条件的节点才能进行静态合批：
引擎目前提供两套动态合批系统，instancing 合批和合并 VB 方式的合批，两种方式不能共存，instancing 优先级大于合并 VB。
要开启合批，只需在模型所使用的材质中对应勾选 USE_INSTANCING 或 USE_BATCHING 开关即可。
通过 Instancing 的合批适用于绘制大量顶点数据完全相同的动态模型，启用后绘制时会根据材质和顶点数据分组，每组内组织 instanced attributes 信息，然后一次性完成绘制。
合并 VB 合批适用于绘制大量低面数且顶点数据各不相同的非蒙皮动态模型，启用后绘制时会根据材质分组，然后每组内每帧合并顶点和世界变换信息，然后分批完成绘制
通常来说合批系统的使用优先级为：静态合批 instancing 合批 合并 VB 合批。
骨骼动画是一种常见但类型特殊的动画，我们提供了 预烘焙骨骼动画 和 实时计算骨骼动画 两套系统，针对不同方向的需求，分别优化。
这两套系统的唯一开关就是 SkeletalAnimation 上的 useBakedAnimation 开关，启用时会使用预烘焙骨骼动画系统，禁用后会使用实时计算骨骼动画系统，运行时也可以无缝切换。
目前所有模型资源在导入后，prefab 中全部默认使用预烘焙系统，以达到最佳性能。我们建议只在明显感到预烘焙系统的表现力无法达标的情况下，再使用实时计算系统。虽然两套系统可以在运行时无缝切换，但尽量不要高频执行，因为每次切换都涉及底层渲染数据的重建。
基于预烘焙系统的框架设计，蒙皮模型的 instancing 也成为了触手可及的功能，但要保证正确性还需要收集一些比较底层的信息。
这里的根本问题是，同一个 drawcall 内的各个模型使用的骨骼贴图必须是同一张，如果不是同一张，显示效果会完全错乱。所以如何将动画数据分配到每张骨骼贴图上，就成为了一个需要用户自定义的信息，对应在编辑器项目设置的 骨骼贴图布局面板 进行配置。
注意 ：
目前底层上传 GPU 的骨骼纹理已做到全局自动合批复用，上层数据目前可以通过使用 批量蒙皮模型组件（BatchedSkinnedMeshRenderer）将同一个骨骼动画组件控制的所有子蒙皮模型合并：
Cocos 3.x camera
参考
Unity3D Camera设置结合OpenGL详细解读
Unity 对Camera 属性Clear Flags 的SkyBox/Solid Color/Depth Only深度解析
每帧绘制完后，都需要清空各种缓冲区，最主要的是color和depth，一个负责画面最终呈现的颜色，一个负责景深。重要的是，在当前Camera范围内color和depth会有被覆盖的可能性。在范围外的color和depth有被其它Camera使用的可能性。这里的清除很多时候是为了处理，在当前Camera范围外的区域。
就是用来填充，当前Camera范围内没有被绘制的区域。
没被选中的Layer会被当前Camera给剔除，不会渲染。过滤非选中层的方法有很多，可能都不会调用渲染函数，没必要使用OpenGL的剪裁功能。
正交ortho和透视perspective，以及剪裁平面，就是生成一个矩阵数据。
参考 正交相机与透视相机的区别
正交相机，三只羊一样大。
直接对应了，OpenGL的 glViewport 调用。
当有多个Camera的时候，每个Camera有自己的绘制空间区域和屏幕视口。所包含的物体会通过Camera的范围渲染出来。多个Camera的层级，决定了所包含物体的渲染顺序。这个数字从小到大，越来越靠近屏幕。
通用的几个shader选择，主要处理光照的。
可以把Camera渲染的画面，绘制到一个纹理上，而不是设备的显示缓冲区里。
这个说的是Camera的另一个属性Clipping Planes,这个属性包含两个值Near/Far。举个简单的例子，比如人眼睛，距离人眼睛太近的物体看不清、距离人眼睛太远的物体看不到，这就是Near、Far了。看下图
你看，这个观赏树的近端可以看完整，远景也OK。这个时候Clipping Planes Near == 0.3 Far == 1000
也就是说距Camera小于Near距离的物体被裁剪掉、距Camera大于Far距离的物体被裁剪掉。
那么，怎么能避免物体被裁剪掉，而且还能离摄像头Near=3呢？那就是，把这个景观树单独用另一个摄像头来显示。具体，看下一个知识点。
这个深度，顾名思义，就是摄像机的深度了。 当只有一个摄像机时，这个属性没有意义。 当有大于两个摄像机时，就牵扯到多个摄像机的前后层叠问题了。
Depth值越大，越靠上，也就是越靠外，也就是可以遮挡值较小的摄像机的画面。比如MainCamera就默认为-1，然后新建摄像机就是0，在上边。
那么回到刚才景观树这个问题，如果想用一个摄像机专门展示景观树，而且还在主摄像机中可以看到，那么Depth必然要大一些，在主摄像机的上面喽。接下来，我们就来讨论Clear Flags 的Depth Only啦：
我们先试着把显示景观树的摄像机的Clear Flags设置为SkyBox或者Solid Color，我们会发现主摄像机镜头被天空盒或者纯色挡住了。然后将ClearFlags改为Depth only,我们会发现，景观树成功的嵌入了主摄像机的其他景色中，浑然天成。根据Depth only字面意思来讨论，也就是说，这个时候摄像机的未渲染部分的显示内容取决于深度，未渲染部分显示什么由深度小于本摄像机的内容来决定。
现在回到枪的话题。我做了一个小例子，如图就是场景，其中有三个Enemy,一个Player(蓝色),一个Gun（绿色）：
然后先是只有一个Camera,我们看看效果：
那么我把枪的Layer设置成GunLayer,然后在MainCamera中CullingMask中取消对GunLayer的显示。然后新建Camera，把深度设置为0（因为MainCamera的深度为-1），Clear Flags设置成Depth only，把CullingMask中只勾选GunLayer,那么这个新的Camera就只显示Gun了。调整Camera的位置到适合位置。看效果：
人物举枪的姿势，很自然吧？
接下来，我将专门解析这段话的含义，觉得上面的翻译有些不好，我自己尝试翻译了下
那么我理解的意思就是设置成Depth only的Camera中的物体，将会凌驾在其他任何物体上，当然，只能凌驾在Depth比他小的物体上。不受3D位置的前后影响。能够完整的呈现在观察者面前。
我做实验如下：
我先将一个Enemy顶进了枪里：
再来观察效果：
枪还在外面，没有顶进去。很明显，其他物体的3D位置信息没有体现出来，不然就不是这个效果了。
至此，这个Depth Only，的含义已经很传神了。
参考
cocos3.0官方文档 camera
cocos3.0官方文档 渲染排序说明
Visibility 属性用于设置哪些层级（Layer）的节点应该被相机观察到，可同时选择多个 Layer。注意：从 Cocos Creator 3.0 开始，2D 元素（例如 Sprite）的渲染也遵从 Layer 与 Visibility 的判断，开发者可以根据需要自行调整 Layer 与 Visibility。
当开发者在 Visibility 属性中勾选了多个 Layer 时，Visibility 属性值便是通过将多个 Layer 的属性值执行 | 操作计算得出。
排序是一个很简单的功能，但是最终的呈现却是根据不同平台提供的渲染能力来的。因此，在这里说明一下， 如果遇到了 UI 渲染出错，花屏，闪屏等现象，首先要检查的就是场景里所有相机（Camera 和 Canvas）的 ClearFlag，确保场景里必须有一个相机要执行 Solid_Color 清屏操作。
具体如何设置 ClearFlag，可参考以下几种情况：
如果场景中只有一个 UI Canvas 或者 3D Camera，那么 ClearFlag 属性设置为 Solid_Color。
如果场景中包含 UI 背景层、3D 场景层、 UI 操作层，则：
如图，设计分辨率1080*2000时，默认canvas的camera属性。其中orthoHeight是高度2000的一半。如果设计分辨率是1080*1920，则orthoHeight就是960了。
上图摄像机盒子的厚度是由far来控制的，默认摄像机位置Z是1000，默认Far是2000。如果将far改为1000，则刚好看到canvas的内容。
默认的正交摄像机，改fov没影响。在透视摄像机中，改Fov和摄像机的坐标以及旋转角度，就能得到合适的画面。
新建一个Scene，以下操作全部使用默认配置：
分析：
BUTTON以及CANVAS的LAYER全是UI_2D，其相应的CAMERA，设置的VISIBILITY确保只看到这些，然后使用的DEPTH_ONLY会叠加到场景中的主摄像机上。
根据官方文档所说，场景中的Camera 设置为Solid_Color即可。
如上图，当把模型的scale调大后，会出现面部贴图糊掉。此时改一下camera的near属性即可。
参考
各位大佬，3D模型怎么做适配呀
急！creator3d的适配问题
Creator 3D Camera按宽度适配的解决方案
这里要注意，增加fov会导致屏幕宽高的可视区域都会加大。在特别瘦长的手机屏幕上，为了保证屏幕宽度范围内看到所有模型，就会导致额外看到屏幕顶部和底部更多内容。