英伟达 RTX 40 显卡海外促销，送《暗黑破坏神 IV》

水滴梦幻

EZh86 发表于 2023-05-10 16:49


既然你说全部都省，那我就顺着开发者的人力资源来说一嘴了

如果要做到同等水平的光照效果，你所说的烘培路线，要做到全局动态光照水平达到或接近RTGI的水平，是不是需要大量的人工调节和布光？

这里有两个问题：
1. 关卡设计一旦调整，修改过的部分，整个光源放置需要重新人工调节以接近调整前的画面效果
2. 烘培光无法处理实时动态光照的问题，如果需要预先做多份，人工调节和补光本身就是吃开发团队的人力资源的。

因此，在场景光照这个环节，你所谓的影视路线要达到同样的效果，需要更多美术团队的人力资源才能做到。而如果能实现用户机器实时计算，这个成本几乎会完全被省略掉。

你怎么看布光这个环节的人力成本节省？它相较于实时计算哪里节省了？

你错了
游戏用的GPU硬件光追GI效果低
错误多质量差
比影视用CPU渲染和烘焙差远了

影视烘焙主要靠机器CPU算
结果要保存为贴图纹理材质等数据
必须依赖强io存储

人工调节主要体现在展UV上
就个熟练经验活 外包即可省
实际展UV也可软件来展实现自动化
AI加入更加省人工

艺术打光布光是必须的  考验艺术审美
真实环境的影视也不能省

你又错了
烘焙早就可以结合实时物体变动计算光影
就是你不懂的探针缓存技术
PS4早就用了
虚幻5也用探针缓存光照 更加进化 机器处理
依赖io存储解决问题思路


你还是错了
低质量实时光追才是有大量问题
噪点光斑漏光错误多
要重新修改反复调整

反而增加了更多人力时间调整成本

不少游戏宁愿把光追延后甚至舍去

该用户已被禁言

水滴梦幻 发表于 2023-5-10 17:11
你错了
游戏用的GPU硬件光追GI效果低
错误多质量差

既然你一再提探针，我们就来好好说一说探针，看看探针和实时光追的区别吧。

以下为资料引用：
探针（Probe） 或者说 光照探针（Light Probe），简单理解就是场景中的一个点然后给予这个点去往四面八方收集光照或者说探测光照的能力，并把以 irradiance map 的形式记录下来（其实就是记录周围的光照，即光场）。在我们对某个 shading point 渲染的时候，就可以利用它附近 probes 的光场信息粗略估计出它所受到的光照。

基于预计算的 Probe 方案往往意味着需要进行预放置（代表着人力成本），主流有三类放置方式：Tetrahedral Tessellations，ILC，VLM，由于虚幻4.18之后主要改用VLM，我们就来说说这个好了。

Volumetric Light Map, 即 VLM（体积光照贴图），也是 UE4 的方案，它使用网格（Grid）采样点保存 probe 数据，而在静态物体表面附近，会对网格进一步细分。
VLM 通过 GPU 来寻找物体周围的 probe ：所有 probe 的数据将烘焙至贴图中，不同细分层度的网格将使用 level 不同的贴图，这样可以方便地在 GPU 中进行逐像素的三线性插值
VLM 比 ILC 的 probe 要多更多，从而 VLM 的 GI 效果更佳，但要存储的数据更多
VLM 的存储结构决定了可以通过 GPU 算法来寻找 probe，这比传统的 CPU 算法性能更加可观（即便 VLM probe 数量要多得多）
VLM 更适合将 probe 应用到体积雾效果中，这是因为 ILC 往往不在几乎没什么物体的空间放置 probe

烘焙光照信息
基于预计算的 Probe 方案在收集光照信息的时候，也采取预计算（烘焙）的方式。这意味着只能对静态光照（静态光源、静态物体组建成的静态场景）进行收集。

SH lighting
在离线阶段，每个 probe 会通过比较高质量但耗时的渲染方式，（如path tracing等，就是2077的路线追踪技术）来收集静态光照，说白话也就是在 probe 上往四面八方去探测光照。同时，探测到的静态光照信息信息将以 SH 的方式（而不是 irradiance map）的形式记录到该 probe 中。

重建 shading point 光照信息
有了预先放置好的 probes ，又有它们各自预先烘焙的光照信息（SH 系数），那么我们就可以在运行时对 shading point 着色：

根据 shading point 的世界坐标找到其邻近的 probes
对这些 probes 的 SH 系数以距离为权重进行混合，得到 shading point 的 SH 系数（比较粗糙的光照信息）
根据 SH 系数就可以重建 shading point 的光照信息信息

优缺点
优点：
预计算能够节省大量的计算来实现还可以的 GI 效果

缺点：
由于是预计算，因此不支持动态光照
对于大场景需要很多的存储空间，并需要设计一定复杂程度的空间结构来管理查询


总结一下：
探针还是一个在硬件性能不足时的性价比方案，通过人工摆放一定密度的探针，来避免完全实时计算的性能开销，在大多数时候能够做个八九不离十，但处理更复杂的真实环境仍有缺憾，如果静态场景中出现多个动态光照，例如多辆车的灯，多个角色开火或释放技能的光照等，仍然无法很好地处理。

因此，本质仍然是用人的工作量去补设备缺乏的机能。

南夢芽

你送个游戏显卡就卖得出去了？

黑翼天使x

我只想知道有几个游戏支持DLSS3.0

水滴梦幻

EZh86 发表于 2023-05-10 18:02


既然你一再提探针，我们就来好好说一说探针，看看探针和实时光追的区别吧。

以下为资料引用：
探针（Probe） 或者说 光照探针（Light Probe），简单理解就是场景中的一个点然后给予这个点去往四面八方收集光照或者说探测光照的能力，并把以 irradiance map 的形式记录下来（其实就是记录周围的光照，即光场）。在我们对某个 shading point 渲染的时候，就可以利用它附近 probes 的光场信息粗略估计出它所受到的光照。

基于预计算的 Probe 方案往往意味着需要进行预放置（代表着人力成本），主流有三类放置方式：Tetrahedral Tessellations，ILC，VLM，由于虚幻4.18之后主要改用VLM，我们就来说说这个好了。

Volumetric Light Map, 即 VLM（体积光照贴图），也是 UE4 的方案，它使用网格（Grid）采样点保存 probe 数据，而在静态物体表面附近，会对网格进一步细分。
VLM 通过 GPU 来寻找物体周围的 probe ：所有 probe 的数据将烘焙至贴图中，不同细分层度的网格将使用 level 不同的贴图，这样可以方便地在 GPU 中进行逐像素的三线性插值
VLM 比 ILC 的 probe 要多更多，从而 VLM 的 GI 效果更佳，但要存储的数据更多
VLM 的存储结构决定了可以通过 GPU 算法来寻找 probe，这比传统的 CPU 算法性能更加可观（即便 VLM probe 数量要多得多）
VLM 更适合将 probe 应用到体积雾效果中，这是因为 ILC 往往不在几乎没什么物体的空间放置 probe

烘焙光照信息
基于预计算的 Probe 方案在收集光照信息的时候，也采取预计算（烘焙）的方式。这意味着只能对静态光照（静态光源、静态物体组建成的静态场景）进行收集。

SH lighting
在离线阶段，每个 probe 会通过比较高质量但耗时的渲染方式，（如path tracing等，就是2077的路线追踪技术）来收集静态光照，说白话也就是在 probe 上往四面八方去探测光照。同时，探测到的静态光照信息信息将以 SH 的方式（而不是 irradiance map）的形式记录到该 probe 中。

重建 shading point 光照信息
有了预先放置好的 probes ，又有它们各自预先烘焙的光照信息（SH 系数），那么我们就可以在运行时对 shading point 着色：

根据 shading point 的世界坐标找到其邻近的 probes
对这些 probes 的 SH 系数以距离为权重进行混合，得到 shading point 的 SH 系数（比较粗糙的光照信息）
根据 SH 系数就可以重建 shading point 的光照信息信息

优缺点
优点：
预计算能够节省大量的计算来实现还可以的 GI 效果

缺点：
由于是预计算，因此不支持动态光照
对于大场景需要很多的存储空间，并需要设计一定复杂程度的空间结构来管理查询


总结一下：
探针还是一个在硬件性能不足时的性价比方案，通过人工摆放一定密度的探针，来避免完全实时计算的性能开销，在大多数时候能够做个八九不离十，但处理更复杂的真实环境仍有缺憾，如果静态场景中出现多个动态光照，例如多辆车的灯，多个角色开火或释放技能的光照等，仍然无法很好地处理。

因此，本质仍然是用人的工作量去补设备缺乏的机能。

你拿虚幻4.18这个2017年的版本说事有多少意义？

而且路径追踪是很早的技术
之前就是CPU计算
影视游戏也用

静态是收集时

探针本来就可以机器处理和手动放置或调整


虚幻5把Probe探针应用到更深的地方了

Lumen是一个基于Probe的RTGI系统

通过Probe执行Ray Tracing


机器处理数据存储加载再计算

该用户已被禁言

水滴梦幻 发表于 2023-5-10 20:33
你拿虚幻4.18这个2017年的版本说事有多少意义？

而且路径追踪是很早的技术

上面说探针的局限，是告诉你探针和实时光追的优缺点，一样还是用调试的人力换客户机上的性能。只要探针的基础原理不变，lumen的探针也一样还是有这些问题。

不过，讨论不要跑题，我们回到起点，提这些是因为你说强存储和烘培能节省开发团队的人力成本
而经过以上分析，相对于全局实时光追而言，你所谓强存储路线上，烘培和探针的使用并没有节省开发团队的人力成本

你怎么看这个开发团队的人力问题？如果你说节省了，请具体说明节省在哪里

水滴梦幻

EZh86 发表于 2023-05-10 18:02


既然你一再提探针，我们就来好好说一说探针，看看探针和实时光追的区别吧。

以下为资料引用：
探针（Probe） 或者说 光照探针（Light Probe），简单理解就是场景中的一个点然后给予这个点去往四面八方收集光照或者说探测光照的能力，并把以 irradiance map 的形式记录下来（其实就是记录周围的光照，即光场）。在我们对某个 shading point 渲染的时候，就可以利用它附近 probes 的光场信息粗略估计出它所受到的光照。

基于预计算的 Probe 方案往往意味着需要进行预放置（代表着人力成本），主流有三类放置方式：Tetrahedral Tessellations，ILC，VLM，由于虚幻4.18之后主要改用VLM，我们就来说说这个好了。

Volumetric Light Map, 即 VLM（体积光照贴图），也是 UE4 的方案，它使用网格（Grid）采样点保存 probe 数据，而在静态物体表面附近，会对网格进一步细分。
VLM 通过 GPU 来寻找物体周围的 probe ：所有 probe 的数据将烘焙至贴图中，不同细分层度的网格将使用 level 不同的贴图，这样可以方便地在 GPU 中进行逐像素的三线性插值
VLM 比 ILC 的 probe 要多更多，从而 VLM 的 GI 效果更佳，但要存储的数据更多
VLM 的存储结构决定了可以通过 GPU 算法来寻找 probe，这比传统的 CPU 算法性能更加可观（即便 VLM probe 数量要多得多）
VLM 更适合将 probe 应用到体积雾效果中，这是因为 ILC 往往不在几乎没什么物体的空间放置 probe

烘焙光照信息
基于预计算的 Probe 方案在收集光照信息的时候，也采取预计算（烘焙）的方式。这意味着只能对静态光照（静态光源、静态物体组建成的静态场景）进行收集。

SH lighting
在离线阶段，每个 probe 会通过比较高质量但耗时的渲染方式，（如path tracing等，就是2077的路线追踪技术）来收集静态光照，说白话也就是在 probe 上往四面八方去探测光照。同时，探测到的静态光照信息信息将以 SH 的方式（而不是 irradiance map）的形式记录到该 probe 中。

重建 shading point 光照信息
有了预先放置好的 probes ，又有它们各自预先烘焙的光照信息（SH 系数），那么我们就可以在运行时对 shading point 着色：

根据 shading point 的世界坐标找到其邻近的 probes
对这些 probes 的 SH 系数以距离为权重进行混合，得到 shading point 的 SH 系数（比较粗糙的光照信息）
根据 SH 系数就可以重建 shading point 的光照信息信息

优缺点
优点：
预计算能够节省大量的计算来实现还可以的 GI 效果

缺点：
由于是预计算，因此不支持动态光照
对于大场景需要很多的存储空间，并需要设计一定复杂程度的空间结构来管理查询


总结一下：
探针还是一个在硬件性能不足时的性价比方案，通过人工摆放一定密度的探针，来避免完全实时计算的性能开销，在大多数时候能够做个八九不离十，但处理更复杂的真实环境仍有缺憾，如果静态场景中出现多个动态光照，例如多辆车的灯，多个角色开火或释放技能的光照等，仍然无法很好地处理。

因此，本质仍然是用人的工作量去补设备缺乏的机能。

你又错了

好莱坞影视都用虚幻5配合CPU烘焙制作
怎么可能品质不好？
单GPU实时硬算比不了

超复杂大规模场景烘焙
实现逼真全局光照和光线反弹效果
并直接将这些效果应用到光照贴图材质中

而且烘焙时间大减
由8小时减少到1小时
用了多台工作站集群渲染

现在超多核CPU成本大降

有利于影视游戏制作路线

该用户已被禁言

水滴梦幻 发表于 2023-5-10 21:04
你又错了

好莱坞影视都用虚幻5配合CPU烘焙制作

我说的是探针和实时光追在解决动态光照问题上的对比，你回答的东西和这有什么关系？

该用户已被禁言

水滴梦幻 发表于 2023-5-10 21:04
你又错了

好莱坞影视都用虚幻5配合CPU烘焙制作

算了，别的也不说了，既然你这么多次提到虚幻5和lumen

那我就问一句，在当下的虚幻5之中，lumen和烘培光是如何合作生成光照的？

水滴梦幻

EZh86 发表于 2023-05-10 20:51


上面说探针的局限，是告诉你探针和实时光追的优缺点，一样还是用调试的人力换客户机上的性能。只要探针的基础原理不变，lumen的探针也一样还是有这些问题。

不过，讨论不要跑题，我们回到起点，提这些是因为你说强存储和烘培能节省开发团队的人力成本
而经过以上分析，相对于全局实时光追而言，你所谓强存储路线上，烘培和探针的使用并没有节省开发团队的人力成本

你怎么看这个开发团队的人力问题？如果你说节省了，请具体说明节省在哪里

你说的是过时又错误的

优缺点也是胡言乱语

哪有多少人工


Lumen就是全动态全局光照的意思
本来就没你说的问题
而且就是基于探针的实时光追全局照明系统

你为何割裂两者密不可分关系？

我说的是io存储能省各种资源
你哪里能否定

说的例子过时又误解
根本就不成立