Hi, I have a wired lumen reflection problem
as this picture, the SM_TVStand use a reflective material, and it should not reflected the cloud in the red arrow position, all the reflection of the outter view should come from the window! Does anybody encountered this?
this is the setting i’m using in this scene @
This is interesting, and somewhat strange. The first things I’d suggest would be to disable screen traces and then assess your scene, view-dependant lighting can make things hard to debug. Beyond that, are you using software or hardware ray-tracing? Software ray-tracing requires a minimum surface thickness of 10cm in order to render consistently into lumen , so you may be looking at light-leaking from that.
Any idea how to get rid of these shadows? I’ve narrowed it down to being related to r.Lumen.ScreenProbeGather.RadianceCache. When I turn that cvar off it disappears (although it’s very noisy when I turn it off) It also seems to be connected to the skylight and/or hdri’s. When I use rect lights without any skylight or hdri the probe shadows aren’t present. I don’t mind turning off the cvar but I’m not sure how inner connected it is to lumen and if I’m going to be losing out on quality somewhere by disabling it. I do cinematics so performance isn’t as much of an issue. Any idea’s would be great.
This issue also is brightness-related.
As is clearly visible here, it becomes more visible in less bright areas (to the right):
No idea what it si though, but I think it is just lumens lighting-grid that affects the world.
Yeah Brightness/Exposure just makes it more noticeable. Even if I crank up the brightness or exposure the shadows are still there. I read the docs on lumen and from what I gather it’s related to the screen probes for World Radiance Cache which are used for distant lighting. It seems the spaces between the probes are causing the shadows. Completely goes away If I’m not using a skylight/hdri. I just don’t know if it’s possible to fix this or if it’s just something you have to deal with.
My solution/workaround is to have some light sources there, which will hide the effect very well. (And in my case, thse light sources also are decorative, win/win situation.)
This issue probably affects “flat/simple” surfaces way more than others, since anything with an actual texture would cover up these patterns pretty well - sand/rocks etc. for example.)
In general, low-light scenes and “simple surfaces” arent the best combination for Lumen, at least from what I figured out the last year.
Lumen definitely has some interesting (hidden) requirements. Working best on opaque, rough, textured geometry. Their screen probe-world probe system is very powerful, relatively scalable, but also important, and I’m excited to hear they’re planning on adding ‘hit lighting’ options for many more aspects of lumen: multi-bounce GI without the lumen scene radiosity, multi-bounce reflections, and perhaps even improved translucency. At least the tech is more scalable than many alternatives.
Hey guys. is it possible to turn on lumen reflections without global illumination?
Yes, actually, but I believe you need to do a few things before hand:
On all of your lights, set your Indirect Intensity to 0.
On every mesh you have, toggle Affect Dynamic Indirect Lighting off.
Lastly, set r.Lumen.ScreenProbeGather.ScreenTraces 0.
Hey, I wanted to share some findings of what I think is a limitation.
If someone actually know what is happening I would appreciate any feedback.
Ray Traced Translucency seems to behave differently in 5.0.2 and 5.0.1
What is unexpected is that it is way more broken in 5.0.2
^ here we see a groom on the car and a Niagara Fluids system. This is in engine version 5.0.1
^ Here is exactly the same scene in 5.0.2
This behaviour persists in other cases. If I have any fog material behind the translucent object it renders as opaque. If a fog material intersects the Translucent object it cuts it like below
I am pretty sure this isn’t new behaviour. However it seems to be behaving better in a previous version. Has this happened to anyone?
Anyone knows a workaround (while using raytraced refractions)?
Does anyone know if it’s in their plans to improve on raytraced translucency soon?
Thanks
While I’d need to know more about the fog material in question (blend mode, shading model, etc) to understand the particular behavior, my understanding of the RT pipeline (RTGI, RT reflections, RT translucency) is that they’re not in any further development, and lumen will take precedence. So while more features of RT translucency will probably be rolled into Lumen, I’d doubt if the standalone feature would receive more support.
By the way, have you changed your DOF mode or settings? DOF makes transparency sorting and blending decently strange, even on the newest features. Furthermore, UE5 got support for order-independent transparency, which may solve what looks to be your sorting problem, if you can take the hit to perf.
Hey,
I have tried with different materials. From a simple translucent material to a more complex volume fog.
i have messed with per vertex translucency, sorting priorities (when availeable) and many other settings. Results are the same. Anything that uses transparency is broken while rt translucency (with refraction) is on. Even a default niagara fluids gas emitter appears all black.
I have noticed these problems begore and you even helped me back then if im not mistaken. I wrote because I found it weird that it is working decently in 5.0.1 but completly broken in 5.0.2.
But I haven’t knowingly altered DOF in the project other than setting quality to max.
This is for rendering in MRQ so I can do whatever achieves best quality. What can I do about DOF.
I appreciate the help
I thought I did, and I even went to check, but I thought the post I found had a different username, my mistake.
Have you found the hotfix list for 5.0.2? I’ve been trying to dig it up but haven’t been able to find it. There may be some explaination there, potentially.
If it’s MRQ rendering, I’d honestly just go with the path-tracer if you can afford it, the denoiser lowers the sample count to something generally easier to swallow. In the PPvolume, path tracing has a ‘high-quality DOF’ toggle that makes the path-tracer actually simulate DOF instead of adding it as a post-process. I used that method and it solved some strange sorting issues for me in a test.
I hope your project goes well by the way, it still looks extremely interesting and the groom on the vehicle is fabulously inspired. Given the combination of multilayer hair and translucency, I definitely think it’s good you’re working with MRQ, for anti-aliasing if nothing else.
Hey all, I am running into a discrepancy between Lumen and Pathtracing where if I have a viewport open in editor with it set to Lit with Lumen enabled and another viewport with Pathtracing going; the Lumen viewport has a slightly dark and yellowish tint to it compared to the Pathtracing one. I am hoping to get Lumen to look closer to the result the Pathtracing is giving. Any suggestions for where to look to fix this would be hugely helpful.
That is deffinitly interesting. We stopped pondering Path tracing because when we started the project in EA1 it still hadn’t been updated. Do you reckon it works well with niagara flluids, translucency and grooms?
We have already used fluids a bit and probably wouldn’t want to delete them.
Thanks a lot for the feddback you should get a badge or something!
Much appreciated! Honestly, I’m just trying to pay it forward. I struggled a lot early days of my journey with Unreal, and the forums were one of the reasons I made the progress I made. I also took the time in EA to test out every CVar and permutation I could find, so I want to help people encounter less of the frustrations I had to.
The good news is I can confirm that UE5’s PT supports all of those things. I’ve had success with Niagara Fluids (including SLW), advanced translucency (but it will need tuning as raster behavior is still different from RT), and grooms.
Grooms do work in 5.0.2, you’ll just get slightly different lighting behavior because raster and RT haven’t been calibrated against each other, but nothing game-breaking. Niagra fluids (gasses at least) worked perfectly for me in 5.0.2, including emissively lighting the scene in a way that not even lumen supports.
FAIR WARNING: grooms can get very slow under particular circumstances. Optimizations were made that let the PT evaluate grooms more efficiently, but they don’t always seem to work for reasons I’ve yet to figure out. They may be very performant (I’ve tested several character grooms running at once) or they might slow down your process, you’ll just need to test and tinker I’m afraid.
There are solutions to some potential problems here, but they will depend on your team size to an extent. By the way, do you know how many fibres are currently composing your main groom on the car?
Update: upon further testing, PT does not play well with 3d niagara fluids in 5.0.2. A main build I compiled worked well, but it seems you can only get dependable behavior via 2D fluids.
Thanks. I’ll deffinitly make some tests then.
To answear to your second post, we’re two on unreal. None with programming expertise.
The car hass 116k strands. Might be overkill.
EDIT: just saw the last post. Well i’ll try it nonetheless. If it has worked before chances are it will work in a future release. Thanks!
