unity 不再渲染局部_UNITY渲染为什么不把模型拆分，即使只有一个顶点在摄像机内也要把整个模型渲染出来？...

这个问题很有趣，作为确确实实这么实现过，并完整的表现出来的开发者，我来详细说一下为什么这些引擎不这么做。

首先，你说的将模型拆分的技术如果猜的没错应该是Cluster Rendering，我首先实现了最基础的模型拆分和绘制部分：MaxwellGeng：GPU Driven Pipeline — 工具链与进阶渲染​zhuanlan.zhihu.com

后来又在这基础上开始使用Unity Scriptable Rendering Pipeline作为主要开发平台，实现了一套遮挡剔除效果，因为Cluster拆分更加均匀的原因，这种方法比老一辈的八叉树之类的算法精度和效率都要高的：MaxwellGeng：Hi-Z GPU Occlusion Culling​zhuanlan.zhihu.com

只有白模肯定不行，我又实现了一套虚拟材质系统，总的来说就是把贴图合成一张大Atlas，或TexArray，亦或是DX12提供的Bindless Texture，考虑到现在PC的DX12实在尴尬，这里先用的大贴图来做。

此类绘制方法常用于开放世界，大地形，那么没有流式加载肯定不行：MaxwellGeng：基于Unity3D的大地形研究(1)：Cluster Async Load​zhuanlan.zhihu.comMaxwellGeng：基于Unity3D的大地形研究(2)：资源序列化与材质加载​zhuanlan.zhihu.com

最后整理一下开发小结：MaxwellGeng：GPU Driven Rendering Pipeline 开发小结​zhuanlan.zhihu.com

再回到问题，这套我大动干戈实现的技术，现在其实我自己的项目并没有在用，为什么呢。因为它表面看起来光鲜亮丽，实际上在项目中带来的问题还是不少的。

首先Cluster的拆分是很慢的，这东西可以说比较难以做到实时，即使我已经把算法做了不少优化，但是可能拆一大片模型还是需要在离线提前烘好，这首先就导致了应用范畴的限制；每个Cluster都是不一样的，所以无法储存矩阵坐标系，这就导致所有顶点都得硬碰硬的存到显存里，给显存容量和IO(主要是IO，模型一般不会特别大，充其量几百兆)带来很大的压力，显存性能骤降；因为要整体拆分整体提交，那么材质的限制是非常大的，整个场景使用统一的材质，那么这个材质可能要算非常多的东西，甚至要加不少分支，GPU消耗喜加一。到最后就是，可能有6个核心或者8个核心甚至是笔者的10个核心CPU在一边打麻将凑热闹，然后GPU忙成狗……

那么这个过程可不可以放CPU做呢，答案是完全可以的。CPU提交Draw Primitive的原理我这里就不多讲了，但是模型切割绝对是当CPU资源空闲时的一个好办法。一些老引擎，提交效率比较低，场景物体一多就会卡，但是现在新的高端引擎对CPU资源的利用越来越合理，譬如Unity的SRP Batcher和Graphics Jobs，或是Unreal Engine新的MeshDraw(这个功能没太了解过，但是看介绍差不多)，所以有时候即使CPU啸叫的非常厉害，性能也不至于太差。而在将大模型拆分的过程中，实际缓解了面数，也就是GPU端的消耗，这种有针对性的，拆了东墙补西墙(划掉)取长补短的方法才是项目中优化的真谛。

最后，Unity是一款商业引擎，商业引擎的定位是用户拿来可以做任何游戏，而不是像模子一样。所以商业引擎最最最忌讳的就是脏，就是功能都往里堆，最后和一个怪物一样，看起来干啥啥都行反而干啥啥都不行，所谓宁缺毋滥就是这样。所以这种周边功能，Unity已经提供了足够的API，有需要的团队可以自己造轮子实现，而且这套系统技术含量也不高，我本人只是业余时间就独立开发完成了，如果有类似想法，可以用划出一定时间来亲自动手测试一下，如果成功了性能提升了，那就把这招记下来，没成功就排查一下失败原因，在以后考虑类似的方案时可以参考一下，这是有利无害的。