unity中框架怎么写( 二 ) _框架

渲染效率的优化上除了与可见性判断有关系，就是那些通用的优化方法：尽量减少渲染状态的切换，按照shader排序渲染，多线程渲染支持。都支持后期处理（hdr, ssao 。）
灯光和材质系统，在表现上可能是差别最大的。
Unity的材质系统需要自己手写shader ，而UE是通过连接图形化的shader表达式节点自动生成shader 。这似乎很高级，但是如果会连接这些节点，我想已经距离会写shader不远了，怎么能指望我们的美术同志们会用呢。
效率方面，这些引擎都不会有什么本质的区别，包括作为纯图形引擎的Ogre也不例外。真正担负大量计算工作的是显卡，引擎所做的工作无非就是让显卡尽量不做无用功。
也不要认为一个很好的视觉效果和引擎有多么大的关系，也许他就是一个shader的工作而已。真正好的视觉效果是靠好的美术做出来的。
物理模拟PhysX最早想推自己的PPU ，也就是物理加速卡，将物理计算硬件化，但后来没有成功。被NVidia收购后，就将物理加速的重心移到了GPU上。
现在PhysX与GPU结合的很紧密，可以真正实现大规模的物理效果。这也使得它成为所有商业引擎，乃至自己开发游戏引擎的不二之选。
物理模拟的各种效果，比如刚体铰接，布料运算，流体运动学等等，都是物理引擎支持的功能，游戏引擎只是将这些功能整合到自己的架构中而已。所以对于物理模拟这方面，所有的引擎应该也都支持的差不多，不会有什么本质区别。
游戏基础架构和脚本扩展在这些引擎上面制作游戏，主要方法就是依靠引擎提供的基础游戏架构（场景，游戏对象，资源对象。），使用脚本加入自定义的游戏逻辑功能。
这个基础架构的思想都是从最早的quake引擎来的，功能上都是大同小异，只是实现上有所差别。Unity使用的是.net平台， UE使用的是私有的UnrealScript 。
网络通信都有为局域网多人游戏设计的网络通信功能。在实现上，基本上都是基于UDP ，建立自己的一套网络协议，支持保证和非保证消息，支持游戏对象的状态复制和RPC调用。
虽然称其为局域网通信，并不代表不能通过internet连线。一般可以通过外部的配对服务器或者dedicate server实现internet互联。
这种网络模式与MMO游戏有着很大的区别。首先，这种模式虽然在概念上也是C/S结构，但是并没有像MMO这样明确的区分client和server 。
在这种网络模式上一般构建的都是联机游戏，就是其中一个人建立游戏服务器（自己也是client），其他人连进来开始游戏。其次，这种网络模式没有为大规模在线提供任何的专门的支持，一般支持人数都在64个以下。
如果使用这种网络通信功能来做单机+连线游戏，还是非常的方便的。如果要用来做MMO游戏，这种网络通信功能不可能有任何的帮助，需要完全自己重新建立。
所以一般都会拿这些引擎来制作MMO的客户端。这点就是我所说的最具有console game色彩的部分。
综上所述，泛用型引擎如果用来做console game ，那基本上可以满足所有技术上的要求了。如果用来做MMO ，除了作为客户端引擎，来满足客户端的通用技术需求外，别指望更多了。