UE5.1移动端延迟渲染管线测试与剖析
UE5.1对移动端延迟渲染做了一波大更新，在只使用3张gbuffer(不算SceneColor和Depth)的情况下支持了桌面端全部的shadingmodel，并且对Vulkan、Metal甚至是GLES都做了On Chip Memory的带宽优化。正好前面我刚折腾完Unity 2021.3的延迟管线，就顺便看看UE5.1这边有什么新花样。 官方talk: 虚幻5的移动端延迟渲染技术到底有多好用？ - 腾讯游戏学堂的文章 - 知乎 https://zhuanlan.zhihu.com/p/562673914 经测试&查阅源码后确认支持的feature directional light可以有多盏(必须位于不同light channel), 只有一盏可以投射阴影 point light数量不再有限制, 不支持阴影 spot light可以投射阴影 每个light均只能有一个light channel 物体可以有多个light channel(即可以同时受多个light channel光源影响) 半透明效果正常 gles/vulkan均支持On Chip Memor...
浅谈UE5的C++程序化生成Shader
UE4时代延迟管线对GBuffer的Encode/Decode工作是直接调用shader中的函数来执行的, 如下所示, 这是BasePassPixelShader.usf中的GBuffer Encode: 可以看到调用了EncodeGBuffer()函数, 其定义在DeferredShadingCommon.ush中: 很普通的函数调用,没什么特殊之处. 然而UE5已经放弃了这套系统,并在代码里硬编码: 这个EncodeGBufferToMRT()函数并没有定义在ush/usf文件中, 而是用C++代码在ShaderGenerationUtil.cpp中程序化生成: 不止Encode, Decode也同样改为了程序化生成的方案: 这样的好处显而易见, 相比于用宏控制, C++代码生成更加的灵活可控. 然而缺点也很明显: 难以在C++代码上扩展 修改与调试, 甚至就连UE代码中注释也这样写道: The problem is it then becomes a nightmare to step through and debug the lines 不过我们还是有办...
URP延迟渲染+Native Renderpass踩坑记录
过去两周多折腾URP Deferred + Native Renderpass, 踩了无数的坑, 翻遍国内国外的社区也找不到太多可供参考的资料. 于是在这里简述一下一些不可回避的问题以及其解决方案, 也算是为社区做点贡献. 在开始之前, 我想延迟渲染这种烂大街的玩意就没什么讲的必要了, 而Native Renderpass可能不少人没听过, 这东西底层调用的其实就是vulkan的renderpass/subpass API(metal也有类似的一套), 简单来说就是利用移动端TB(D)R的硬件架构, 相比于传统延迟管线在basepass结束后将gbuffer store回system memory, 之后再在lightpass中load回来这种带宽压力极大的方案, Native Renderpass可以在每个tile的basepass结束后将gbuffer保存在On-Chip Memory上, 以供接下来的lightpass直接使用, 直接优化掉了两个pass之间的store/load操作, 极大减缓了带宽压力, 这种形式的rt也被称之为memoryless. 简单科普到此为止...
从零开始的UE5卡通渲染0x01：自定义着色模型
简单写完了第一篇没啥营养的概述后，这一章我们来做一点真东西，通过修改源码添加一个Custom Shading Model，并使其可以集成我们上一篇文章提到的BaseColor、ILM、SSS贴图进行卡通渲染。 这里我使用的引擎版本是UE5.0.2。 拉取源码版UE5并编译 想要对源码做修改，绝对逃不开的第一步自然就是拉源码和编译。关于这一步，知乎上有大量的资料，官方文档写得也非常详细，我这种懒狗肯定不会再写一遍，不过还是有几点需要注意，值得说一下： 源码工程目录一定要放在固态硬盘里 预留大约250G的硬盘空间 建议整块好的CPU，框框越多越好，再多插几根内存条……不然的话等编译的空闲你还可以抽时间去学学Unity 😃 C++部分 C++部分大多都在进行Shading Model注册、开放和修改数据接口的工作，这里直接上截图。 EngineTypes.h \Engine\Source\Runtime\Engine\Classes\Engine\EngineTypes.h 在枚举EMaterialShadingModel 中注册我们的Shading Model： M...
从零开始的UE5卡通渲染0x00：理论基础
最近在研究基于UE5的卡通渲染，颇有收获。正巧前段时间与同事吃饭，聊到知乎，深感自己知乎各种不正经的东西实在太多了，而我又是个懒得腾出时间写正经东西的懒狗，遂决定趁编译Shader的空闲，写点学习笔记、心得与分享。 虽然卡渲本身的知识不算很多，但放到UE5上就是不得不改动源码的大工程了，不由得让人怀念起自由的Unity，令人感叹……扯远了，总之UE5卡渲这块我准备分成多篇文章，多水一水。 目前的大(feng)致(kuang)计(hua)划(bing)如下： 卡通渲染理论基础 修改源码的卡渲光照模型实现 基于卷积矩阵的卡渲描边实现、添加子Mesh的Backface卡渲描边实现 修改源码自定义Pass的Backface卡渲描边实现 …… 次世代卡渲/独立的Hair、Skin卡渲光照模型/UE5复刻原神ShadingModel……(或许会有？) 废话不多说了，进入正题。 提到卡通渲染，很多了解不多的朋友可能就会将其与NPR(Non-Photorealistic Rendering)混为一谈，可实际上这两者并不能划等号。事实上NPR是个非常广泛的概念，不止是卡渲，油画、水墨风等等...
一个用来ghs的、使用了concept、折叠表达式、模板形参包做基类列表等技巧的模板元编程Mixin Demo
昨天看Mixin时突发奇想，写着玩的。图一乐。 直接上代码，受限于平台，Show()部分自行脑补。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758#include <concepts>#include <iostream>template<typename T>concept IsSexuality = requires{ T::Show(); };template<IsSexuality... Sexuality>struct GirlFriend :private Sexuality...{ constexpr GirlFriend() :Sexuality()... {} constexpr void ShowSexuality() const { std::cout << "...
关于std::optional传递开销的讨论与优化
在讨论std::optional之前，我们应该先适当谈论一下“可空类型”。 我们知道，在传统的C++中，是不存在现代编程语言中常见的“可空类型”（如C#中的Nullable)的，这就导致很多情况下我们无法给一个指针以外的变量或返回值设置一个安全的空值（实际上C++11之前用于指针空值的NULL也并不安全），而需要设置一个人为规定的标记值（Sentinel Value）来将其标识为空。 1234567//C#//size理应为非负uint? size = null; //OK, 通过C#语法糖[int?]标记size可为空，并将size设置为空//C++//因为需要考虑Sentinel Value，故size无法为unsigned int//当size == -1时，size为空int size = -1; //OK，通过人为设定标记值来将size设置为空 显而易见，传统C++使用标记值来对某一变量设置为空的行为相比现代语言是存在问题、丑陋且不安全的： 某些情况下为了考虑标记值不得不放弃最为合适的数据类型（比如unsigned int之于size） 其他使用者容易忘记甚至不...
从auto_ptr到unique_ptr：浅谈C++右值引用、移动语义与智能指针
std::auto_ptr是C++03对智能指针的第一次尝试，作为一个失败品，其甚至已然在后续的标准中被移除，但时至今日，我们依然可以透过它一窥C++发展史的一角。 出于方便、严谨起见，下文所提及类与函数，如未特别标明命名空间，均为std或其子命名空间下的标准库设施。 std::auto_ptr的失败之处 auto_ptr在语义上是有些类似它的后辈unique_ptr的，其拷贝构造/赋值函数并非深拷贝或浅拷贝，而是被设计成了资产的所有权转移即move语义，从而保证一份资源同时只能被一根auto_ptr所持有： 1234567891011121314template <class _Ty>class auto_ptr {public: auto_ptr(auto_ptr& _Right) noexcept : _Myptr(_Right.release()) {} _Ty* release() noexcept { _Ty* _Tmp = _Myptr; _Myptr ...
来点图程破防乐子
快过年了，不要再讨论什么C++，图形学，模板元之类的了，你带你的C++语言的设计与演化回到家并不能给你带来任何实质性作用，朋友们打开UE4连连看就做出了好看的特效，你默默的在家里瞪着两眼看GAMES、may佬和侯捷的视频。 亲戚朋友们吃饭问你收获了什么，你说我读完了RTR4和PBRT，系统的研究了基于物理的渲染和非真实感渲染，还用C++20重构了自己的渲染器。亲戚们懵逼了，你还在心里默默嘲笑他们，笑他们不懂C++和计算机图形学，不懂光照方程，不懂RAII和CRTP，也笑他们连Shader是什么都不知道。 你父母的同事都在说自己儿女一年的收获，有的用Java做了个网站后端赚到了第一笔外快，有的用Python做了点数据可视化发到B站成了up主，有的学了Unity和C#做独立游戏已经发售了。 你的父母默默无言，说我的儿子买了一整套的Effective C++，上Stack Overflow痛骂了C++标准委员会，写了一堆狗屁不通报错几百几千行的模板元编程代码，还对着谷歌翻译啃Ray Tracing the Rest of Your Life，人也越来越魔怔了。 原文链接: https...
