MRQ rendering Hair has noise

[Image Removed]

MRQ渲染Hair有噪点

用MRQ渲染Hair,当动态大的时候,噪点难以接受

已知这是时间积累不够导致,理论上增加离线渲染的临时采样数,也就是一帧渲染32或者64次,当足够多的样本混合在一起噪点就消失了,但是实时动态计算的Groom并不适合这样渲染,会抖动,(一帧渲染一次则是流畅的),也许用缓存可以解决抖动问题但成本太大,有办法同样只渲染一帧,但是牺牲更多的时间来换取丝滑的品质吗?(类似视口里暂停时的结果,此时TSR质量会无限积累,直到完全没有噪点。)

————————————————————————————————————————————

MRQ rendering Hair has noise.

When rendering Hair with MRQ, when the dynamics are high, the noise is unacceptable.

It is known that this is caused by insufficient temporal accumulation. Theoretically, increasing the temporal sample count for offline rendering, such as rendering 32 or 64 times per frame, would eliminate the noise when enough samples are blended together. However, the real-time dynamically computed Groom is not suitable for this kind of rendering, as it causes jitter (rendering once per frame is smooth). Perhaps caching could solve the jitter problem, but the cost is too high. Is there a way to render only one frame but sacrifice more time to achieve smoother quality? (Similar to the result when pausing in the viewport, where TSR quality accumulates infinitely until there is no noise at all.)

MRQ离线输出极大依赖时间和空间采样来实现抗锯齿,提高渲染精细度和品质。不仅仅是毛发的品质,其他各种效果都能受益,比如Lumen,dither的mask材质,Volumetirc fog等一些都大量依赖时域补偿收敛提高品质的效果。我认为正常的思路是毛发(strands)动画做缓存(可以在编辑器里的做);MRQ关闭TSR;开启Temporal samples给予足够的数量,需要的话开启Motion blur来做进一步的平滑融合。

如果实在需要单帧实现尽量高品质尝试,Screenpercentage提高到150或更高(如果显卡吃得消),不让TSR去做upscaling,但依旧打开TSR做抗锯齿,应该会好一些。

感谢解答,又见面了

用缓存解决是我们的共识,不过缓存非常麻烦,数据庞大且不利于动画迭代。

有时候动态都很接近不动,需求简单,实时计算效果完全满足需要。

然后我发现实际上可以解决抖动:

当Groom计算子步为5,每秒30fps,MRQ临时采样数(子帧)=1,则正常。

当Groom计算子步为5,每秒30fps,MRQ临时采样数(子帧)=32,则疯狂抖动。

当Groom计算子步为50,每秒30fps,MRQ临时采样数(子帧)=32,则正常。

当Groom计算子步为50,每秒240fps,MRQ临时采样数(子帧)=32,则疯狂抖动。

这说明,毛发的子步只基于固定的时间和帧率,不考虑实际帧率,不考虑MRQ的多个子帧,一个项目可能帧率是统一的,但MRQ情况复杂,有的镜头需要子帧8,有的需要32,有的需要128,如果想渲染出相同groom动态品质,需要改三次groom资产,这在流程上比较不科学。

是否考虑改进Groom的逻辑使其考虑实际帧率和MRQ子帧数量?如果基于实时Play性能考量,或许可以开放一些CVar来允许用户调试。

这个问题和这个主题(噪点)不同,需要提一个新单吗

感谢分享测试结果;看上去当Temporal sample的时间间隔小于Groom 物理模拟的Substeps后的时间间隔会产生问题。理论上Substeps足够大数值​就可能避免问题发生。但很大的Substeps可能造成实时交互时时编辑器里模拟的效率。

目是substeps应该是基于固定24fps;有个​r.HairStrands.EnableAdaptiveSubsteps但目前没有任何作用,估计有考虑你说的基于实际帧率来做substeps的需求,但至少当前或可见的将来还未有。

暂时不需要,如果讨论深入复杂再说

期待推进这个功能

另外提一下groom cache引擎内cache的大小除了帧数多少,主要取决于guides的数量段数影响;适当降低guides数量和点数可以很大程度减少数据量