I suppose when you are talking about black metallic reflections, your are seeing that while using “Hit Lighting for Reflections” with Hardware Ray Tracing enabled.
Feel free to tweak that “Fallback” value, especially when dealing with a rougher metallic material it would probably go a bit higher in value (0.5) and make it look a bit darker but not completely black. One could probably go further and remap Roughness to Metallic Fallback and let it change dynamically and accordingly. But that’s for another day …
You will probably end up with very similar looks + proper opacity in reflections + properly rendered Niagara particles in reflections + nicer direct shadows (VSM) in reflections.
Just turn off SSR: ShowFlag.LumenScreenTraces 0
BTW, I think that “Normal” input label is a bit misleading as some may think it has something to do with the normal vector / map. It does not. “Default Material” sounds probably better?
GI = Lumen
Reflections = Lumen + Hit Lighting for Reflections
Translucency = Ray Tracing (but Raster gives the same result)
Support Hardware Ray Tracing = True
Shadow Method = VSM
Cast Ray Traced Shadows on Directional Light = False (when set to True, the first ball on the left starts casting shadows but then the Nanite ball starts getting artefacts, undesirable but that’s how it is atm)
Let’s focus on the first ball from the left.
Why can I see shadows in the reflection but not in the main pass and at the same time I cannot see the mesh in the reflection? Clearly its shadows are being rendered.
Would it be somehow possible to reflect at least a solid mesh for translucent objects, let’s say by overriding blending mode?
How about hiding Nanite artefacts when Ray Traced Shadows on lights is enabled ?
I am, good catch. I tried out the same scene with lambertian materials just to see how it worked however, and it resolved noise-free, hence my assumption that it’s the material roughness causing a problem. And also, I would if I could, but lumen’s surface cache is an automatic material parameterization that isn’t user-editable at the moment, hence my problem.
This is a pretty standard problem with Nanite and RT shadows-The nanite proxy mesh looks different than the full-detail mesh, so it has self-shadowing artifacts. No real way to fix it other than crank up the proxy mesh count, but that erases most of Nanite’s gains anyways unfortunately.
You can set different materials and meshes to recieve RT shadows though, so you could disable it on the nanite meshes but maintain it for translucency if you’d like.
As for reflections? Depends on what engine version. Translucent reflections just got enabled in github, but I only know that for reflections on translucency-not whether or not they’re visible in other reflections.
Awesome! I’m trying to figure out how to set a standard material parameter or something, truth be told I wish there was some mechanism by which meshes could figure out their internal materials and then automatically turn to Nanite (EG transparency ignored, anything opaque allowed, etc).
Does UE5 actually support caustics outside of the path tracer, in the sense of diffuse-specular-diffuse lighting? The only branch of UE that I’ve found support for real-time caustics is NVRTX, which is way more of a hassle than it’s worth. I’m just curious, the only features Lumen is really missing at this point is support for light transmission and caustics, and after that I think it can pretty much supercede the path tracer in every area except sheer quality.
In UE5 Preview, you can disable Screen Traces of lumen reflection (r.Lumen.Reflections.ScreenTraces 0) without lose reflection quality. Lumen reflection now resolves entire reflections of the scene. In EA, this didn´t happen (the part of screen traced reflections became black with “r.Lumen.Reflections.ScreenTraces 0” command )
Trying the new high quality translucent reflections option in the ue5-main branch.
Seems to work however I find it impossible to add any imperfections, scratches, smudges etc to my glass.
Tried multiplying in Roughness and Emissive textures but no difference.
Could any Lumen material experts chime in?
I can answer that, I believe. High-quality translucent reflections for lumen are very expensive, as they have to be re-rasterized on the translucency Gbuffer (as opposed to the lower-quality translucency just grabbing a probe sample from the radiance cache). That’s one of the reasons HQ translucent reflections are only supported for the first bounce.
Bottom line: only perfectly specular translucent reflections are allowed, as anything else would require extra denoising and filtering in order to look acceptable. This was the same thing Control did in order to keep their translucent reflections cheap, and while it generally works well, it does have some drawbacks.
It says in the GitHub Changelogs that any translucent surface will be forced to mirror when HQ reflections are on, although I don’t entire understand why that should affect the normal behavior.
Unreal-ated (apologies for the pun), but good news for multiplayer devs: Lumen just got preliminary support for Splitscreen in _main. Furthermore, it looks like VR support is coming along somewhat, and I for one can’t wait to look at the beautiful graphics that will come out of Lumen and Nanite on VR.
I’m not entirely sure, to be honest. I played around with the glass shaders a little, but it’s not quite my area of expertise. It very well may be possible, but given the permutations of which shading model you’re using for translucency, whether it’s ThinTranslucency or traditional, whether you have ray-tracing enabled or not, and other variables, I couldn’t say.
ThinTranslucency, maybe not unfortunately. You could probably use decals to hack in some detail, they’d be lit by the lower-res translucency grid, but still receiving lumen GI.
I think it’s less that it’s impossible to add imperfections to materials, more that you might have to use unconventional methods to make them work. At the core, the optimization is about eliminating having to denoise diffuse lighting, so as long as the normal perturbations are perfectly specular, there shouldn’t be any issue inherently.
Hum… Hard to understand what happens here. As you can see, I have several objects instanced in the scene. Some of them are yellow, some are not. All of them are the same static mesh, so same mesh settings…
I think yellow means lumen could cache the lighting of that surface, but has determined it’s too small, too far away or not enough room in the cache. Most yellow objects get corrected when closer to the camera.
Purple means it won’t ever cache that surface. A small object being yellow isn’t a big deal, screen space should do a good enough job.
