UE4 卡通渲染要点（后期处理方式）

由于UE4对multi-pass支持不好，如果要两个pass实现描边的话，得是两个材质，两个模型叠一起

还有另外一种方式是后期处理方式，用边缘检测的方法，用个卷积核处理一遍深度图，就能得到边缘，在对深度过滤下能对远处的不进行显示，最后得的线核帧融合用Lerp，这样有线条显示线条，没有的显示原来的像素。

地图损坏 打开crash——report文件夹看报错 然后把损坏的地方删了 或者把地图删图 一般这种地图损坏的原因都是卡bug 刷物品造成的。客户端上，距离主摄像机足够远的类会莫名奇妙的重新创建。这个问题找了很久都没有找到原因。于是大胆猜测：会不会是因为勾了replicate，导致不同步时会把客户端上备份删掉再重新从服务器上拷贝，至于为什么只有距离足够远时才出现，怀疑是因为同步率和距离之间有加权，距离摄像机越远越不容易发现所以同步率没那么高也没关系，所以也就很容易造成不同步导致重新刷新。这样怀疑之后在Endplay里print了一下，基本上证实了我的猜测，总算解决了这个诡异的BUG
————————————————
版权声明：本文为CSDN博主「JericoGu」的原创文章，遵循CC 40 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：>

实时渲染强调的是实时性，所谓实时性是指对于每个 *** 作和指令都可以快速的看到结果。比如在云游戏中如果使用了实时渲染技术，则意味着可以不安装游戏程序，登录网页就可以直接玩游戏。但实际上各种指令的执行都是在服务器上完成的，用户自己的电脑设备是单纯的接收指令和以视频的方式呈现各种指令的执行结果。

实时渲染技术简单来说就是，将以前必须安装在本地电脑的3D应用程序放在服务器上，用户通过普通电脑、手机、平板、VR眼镜等设备可以直接使用服务器上的程序，有点类似现在比较流行的云桌面，但延迟比云桌面更低而且能支持的软件类型更多，包括智慧城市数字孪生行业中常用的UE4、U3D，建筑行业的3Dmax、revit、bently、CAD等等。服务器将每一帧数据渲染成一幅画面，然后重新编码通过网络传输，呈现在终端屏幕上，而每一帧的数据，都在不断变化，所以每一帧的画面呈现出来，也在不停地动，因此在终端上就是以视频流的方式呈现出来的。

对于用户来说这种使用和以往的计算机使用习惯没有太大的差别，只需要浏览器打开网址即可，极大的降低了使用的门槛。但从技术角度来说却要复杂的多了。

实时渲染

UE4官方文档中《Graphics Programming Overview》开篇即说：UE4的渲染代码太多故难以从宏观上快速预览它的全貌(There is a lot of rendering code in Unreal Engine 4 (UE4) so it is hard to get a quick high level view of what is going on)。这一官方说辞从侧面说明了UE4渲染引擎的复杂性是很高的，这个说法多少有点推卸责任，也颇具劝退之意。但我们自己做为一个合格的程序员，在做任何技术选型的时候最基本的要求总该是：我选的方案在其内涵和外延上至少要能贴合或拔高项目对该功能块的需求，并且这个方案得是我能全程能Hold得住而不是挖深坑用以自埋的。在这一前提下对UE4的渲染引擎乃至UE4引擎本身做一个宏观的整体性的评估就必不可少了。
当然UE4渲染引擎的FeatureList非常棒且推进迅捷，所以在功能性和前瞻性方面往往大超项目预期，往往并不是评估的重点。许多公司之所以选UE4做为项目的引擎必选项，是因为老板看到基于UE的吃鸡大热，UE4所产出的其它产品和宣传视频也惊艳绝伦，于是乎脑袋一热双手一拍，技术人员就麻着胆子硬着头皮，战战兢兢开始玩弄UE(或者说被UE摁在地上摩擦了）。
本文的内容是从渲染引擎的宏观功能上罗列UE4的覆盖面和划分方式，尚不会涉及到具体每个功能模块的实现细节。本文在讨论渲染模块的时候还假设大家均具备这些图形引擎常识：渲染API的功能范畴、如何组织基础的渲染管线、夸平台图形引擎需要基础框架支持的最小集。
先从顶层来看一次完整的渲染
给渲染器输入以原始的几何和材质数据，渲染器把几何和材质数据转换为渲染API所支持的数据、渲染状态、Shader及Shader参数并由这些数据组装为一个RenderPipeline，然后执行该RenderPipeline,得到渲染结果后交换到渲染的目标Context上去（如Windows下的一个窗口，Android下的一个View等)。一个3D渲染引擎的核心工作就是组织好这一宏观上的工作流，使其最大化利用目标平台的硬件资源（CPU,GPU,内存，硬盘或闪存等）和特性，使其使用最便利、性能最优，效果最佳。
UE4的渲染系统也不例外，所以我们的渲染功能的识别方式的基于以上基本过程和传统的3D引擎功能划分来做。UE4的模块(Module)和我们将要讨论的渲染功能模块不存在一一对应关系，可能UE4的一两个类即实现一个功能块，或一个UE4的模块(Module）除了包含数个渲染相关的功能。
UE4场景和场景管理(Scene 、SceneManager)
在UE4中不存在传统引擎中的严格一一对应的Scene和SceneManager，它的实现是散落在许多类中。
传统引擎中的Scene一般表达一个渲染用的世界。这个概念在UE4中有两个类和它对应：用于游戏线程中的UWorld类和用于渲染线程中的FScene类UE4中的中UWorld和FScene有一一对应关系，UWorld用于游戏线程，用于用户的主动 *** 作（如创建、删除世界中的物件等），而FScene则隐藏于渲染线程，由UWorld和世界中的对象被动 *** 作。在游戏过程中，一般只存在一个UWorld实例（在过渡的时候可能有两个），但在编辑器形态下，一般会存在许多个UWorld对象——一般来说，一个UWorld对象表达一个单独的编辑器窗口。
UE4和其它支持大世界的引擎一样支持游戏场景中的物体动态加载和卸载。但它对于大世界的拆分方式是比较独特的——UE4的场景的划分模式不是基于物件级而是基于子关卡级来做。在UE4中，一个UWorld由一个一直存在的持久关卡(ULevel类)和多个动态加载卸载的子关卡组成。UE4中这种动态加载卸载的子关卡叫做流关卡(StreamingLevel ,ULevelStreaming类)，且场景中的具体物件都是放置在关卡或流关卡中而不是直接位于UWorld中。
UE4中的流关卡的加、卸载策略实现是由UWorldComposition类来负责的。这是一个基于视点距离和流关卡卡包围盒的简单的加载策略实现。
用于渲染线程的FScene不具备复杂的场景管理功能，它有一些数组用于各类管理场景可渲染对象和灯光，它有两个Octree结构用于空间的快速查询——一个用于灯光，另一个用于其它的可渲染对象，它还有一个DrawList用于Cache各个渲染Pass的指令。

UE4系统要求：

1、 *** 作系统：Win10 64位系统。

2、处理器（CPU）：四核Intel或者主频在25或者25以上的AMD处理器。

3、内存：8GB。

4、显卡／DirectX版本：DirectX 11或DirectX 12兼容显卡。

5、声卡：瑞显口英特尔High Definition Audio控制器。

6、网卡：英特尔Ethernet Connection 1219-V /华硕。

UE4的 *** 作工具

虚幻的编辑器（UnrealEd)是一个以“所见即所得”为设计理念的 *** 作工具，它可以很好地弥补一些在3D Studio Max和Maya中无法实现的不足，并很好地运用到游戏开发里去。在可视化的编辑窗口中游戏开发人员可以直接对游戏中角色，NPC,物品道具，AI的路点及光源进行自由的摆放和属性的控制，并且全部是实时渲染的。并且这种实时渲染还有动态的光影效果。

---