【图形渲染-引擎】软光栅真的这么强？为何ue5之前的引擎做不到？

闲鱼技术01 · 发表于 2021-9-22 08:49

搞得你远古ps2时代有光栅单元给你用一样。
大家所有东西手搓——ps2的图形单元本质上是个算力器，虽然有预制模板，但很明显就算现代引擎也不见得能覆盖生产力下的大多数情况。
别说当时了，徒手手搓几千条渲染命令很好玩吗…就算预制模板cv你都得写吐了。
其结果无非就是所有人大骂索尼罪大滔天。
什么之前的引擎做不到，引擎这东西首要的目的是降低工程成本的情况下，尽可能做出能用的东西。
你要真讨论图形效率，像unity这种东西就是标准的你想写都能写的都比他好，七八年前unity本底还是纯单线程（不提供任何多线程优化方案的那种）图形接口只有dx8水平，那个时候dx12都快出了，unity还在折腾固定的顶点和像素，可编程光栅还是个残废，丫的unity啥时候是卖图形的引擎了？你见过这玩意原生有多烂？
拿这东西出来说有啥意思？
但他那套东西烂归烂，出东西还是方便的。
软光栅这种东西在之前明显就是效率不够——没有足够算力给你挥霍的，这几代高性能gpu结构其实都已经更偏向纯算力单元，而之前更偏向图形处理器。（之前固定管线和架构的贡献远大于算力的贡献）
而且这套明显偏技术验证方案，现在的完成度基本不到5% ，压根上不了生产力环境的，实际要上基本都等于重写渲染了，这么简单的东西效率高是因为是你在针对算力编程，所有场景都在针对算力去写，现代图形哪那么简单？
能直接把图形渲染指令简化成浮点玩真是笑死了，你是天才啊。
真的上生产力有这效率才见鬼了。

JoshWindsor · 发表于 2021-9-22 08:52

这个demo的CS软光栅模式只输出了深度。如果要正经用的话，可能得和Nanite一样用visibility buffer的方式，想办法把几何数据（triangleID，barycentric）打包进64位原子计数，再重建出完整的材质属性用于后续渲染。这一套流程走下来不见得一定比F+/deferred直接画要快，实现起来有不少坑，而且这还仅仅只是软光栅的部分……要在商业引擎这种体量的软件里落地这么一套管线，同时要求其满足各种各样奇奇怪怪的美术需求，难度和风险还是不小的。
另外还有一点，现代GPU通用计算性能已经挺高了，把整个GPU的算力都堆上去处理单一任务完全有可能打败某块固定管线，更何况是在小三角形这种传统光栅化有瓶颈的特殊情况下。

DomDomm · 发表于 2021-9-22 08:56

楼上很明显就是个别人说啥就信啥的主，看了UE5 NANITE的方案，就认定一定是最优的方案。。。。然后先入为主，就说没法落地。。。这就是为何国内引擎比不上国外的原因之一吧~~~
首先这个DEMO就没做小三角的筛选，也没做CULLING，单单测试了软光栅，就能渲染上亿个三角形，并且帧率有100FPS。就这个裸模测试，现在的UE4和UNITY，都没法渲染同屏上亿个三角形，并且帧数能有60+的，但上面那个DEMO能渲染的很流畅，所以才有这个提问。是这个老外的软光栅算法牛逼，还是说别的原因。楼上明显没看懂这个提问问的是啥。。。
PS.我补一下老外另外一个DEMO把。。。看是不是不能落地。。。哎。。

Doris232 · 发表于 2021-9-22 09:01

先问是不是，再问为什么！
软光栅化几十年前就很流行了吧，可自行参考Mesa LLVMpipe和Google SwiftShader！

zt3ff3n · 发表于 2021-9-22 09:05

测试样例中软光栅器只输出深度不输出其他参数，不能用于正常的着色。如果利用64bit atomic输出pack后的深度和visibility buffer，效率铁定打折扣。如果硬件本身不支持64bit atomic，那么只能分两个pass分别输出深度和visibility buffer，光栅化效率相当于直接减半

jquave · 发表于 2021-9-22 09:13

ue5的软光栅化也是基于compute shader的，至纯CPU版本的光栅化早就有了，这贴的大佬也都有实现，搜一下吧，于为什么ue5之前。。引擎，DEMO、研究成果和引擎是两回事，引擎是工业产品需要考虑的实用化问题多的去了，没有强大的工程化落地实现能力别谈，以及影响力市场等等

		自动登录	找回密码
密码			立即注册

【图形渲染-引擎】软光栅真的这么强？为何ue5之前的引擎做不到？

本帖子中包含更多资源