Temporal bad, people from different industries bad. Your opinions very important. Games need 200fps and need to not use anything that causes any blurry anything.
My reply to the insulting exaggeration of Braitenbugs post
You obviously just have no idea about what I want.
I said I didn’t have problem with lumens temporal accumulation.
I have a problems with temporal motion smearing(not per object blur) and temporal dependence.
I never said I wanted 200fps. Your rude exaggerations of my views aren’t helping anyone. I have been asking specifically for a 60fps standard.
If you think 60fps is “too much” on 30 series hardware is too much to ask for then good for you. Move on while the people who are actually trying to fix can work in peace.
Btw if you tell someone to just use cvars for high quality renderings in ue5 why dont you just do the same for your requirements? Since its so easy.
This is so poorly written I don’t even understand your question. If you have a movie or pre-rendered cutscene just use path tracing or NvRTX like a regulars studios.
If you a game studio, use the 60fps High Lumen.
Now, that I’m done with that I’ll post what I was going to say.
The flickering Lumen GI issue seen in the default 60fps Lumen is related the screenprobe downscale Cvar. The higher it goes, the less expensive it becomes at the cost of increase the jittering(flickering).
16 from 8 does pretty well, does anyone know of a way to scale down the probe gather calculations in another way since the downscale factor is tied to the jitter process?
I am having a problem and I don’t know if it’s lumen problem or a camera problem. Somehow the shadows on my meshes pop in and out in distance while the camera is moving towards them. How can l solve this?
Shadows would be a direct lighting solution, not an indirect lighting problem. I’d first check your shadowing method, set it to virtual shadow maps and see if that resolves the issue.
I deleted my original post since it was out of line.
Just a reply to solid snake
Hey SÓLíD_SNÁKÉ,
I know my post wasnt great but I’m not the first person in this forum that has a problem with your way of writing and I think you show little respect towards other users here.
I know my english is not the best so I took my time with this one and I hope its clear enough:
You frequently resort to charged statements like “I hate upscalers,” reference the “idiotic TAA tread,” and demand “STOP working on new features!”
You’re making claims such as “Consoles are for casuals,” and suggest that “People buy consoles because they don’t care.”
There’s a clear disregard for other peoples opinions with remarks like “Who in the hell is spreading this LIE?” and “I don’t think you read my post.”
There’s a lot of personal bias in your posts, for example when you assert how “blurry temporal methods are ruining raytracing and gaming for YOU.”
You bring up the same complaints again and again essentially spamming this thread.
So for me your style of communication isn’t fostering a productive discussion.
Lumen (HWRT) hit lighting does not appear to work with lightmapped GI in 5.3. The scene renders in reflections, but without GI or skylight shadowing. Interestingly, deprecated raytraced reflections also don’t render lightmapped GI anymore in 5.3… can’t help but think those two things are related.
If that’s the case, why dont you use Unity, Godot, CryEngine, or any other engine instead of Unreal, if it is so bad? I’m sorry to be the one to point out, but it is very annoying that whenever I see that there are some new posts in this thread, hoping for some new informations about the state of Lumen, I have to read you talking down on the engine and the developers. If you want to tell the devs about your suggestions for a better engine, then please create a seperate thread or find one which is looking for suggestions, but don’t spam this thread. The thread is named “Lumen GI and Reflections feedback thread”, not “SOLID_SNAKE’s suggestions” thread. Me and lots of other devs are checking up on this thread to find some useful informations for our work and future work. So please, respect our time and if you have some suggestions for the engine, create a new thread for it, don’t spam this one. Thank you.
Pffff. Digging into this thread searching for interesting Lumen issues (exposed as feedback) is a pain… I wouldn’t want to be in the bones of the Epic Team… even reading all the messages, as I do.
Here are some observations and suggestions regarding Lumen:
Very important:
Please, remember the bug where multi bouncing reflections are not working in Lumen reflections + baked lighting. (Tested today on 5.4, still missing). This is the cornerstone for Lumen reflections being finally ready to work with baked lighting scenarios, which are still used/preferred by TONS of developers. (Not -only- for multibouncing mirrors, but a mirror reflecting a glossy floor near big windows, for example).
Add the option, cvar, material option, per object option, anything, to enable/disable emissive materials contributing to Lumen GI. Lot of users have already reported this issue, without an effective solution. There are tradeoffs, but always with a negative compensation. Emissives are officially recognised as “better to use big emissive objects” and “better to use low emissive values” to avoid massive noise, by Epic Games. But what happens if we are using a small emissive, because the object is that small? Or if we want to pushup the emissive/bloom effect in a very certain super magical object? The logical solution (if Lumen still can’t handle it correctly) would be to disable the emissive contribution and make it illuminate through a lighting source, but without loosing the emisive effect and/or bloom.
Less important:
Reintroduce the variable “r.Lumen.HardwareRayTracing.MaxTranslucentSkipCount”. As an user pointed, it seems that the current value behaves erratically in some scenarios. Nevertheless, adding an extra variable doesn’t hurt and can provide more flexibility and optimization possibilities. I mean, “why not”?
Increase the Lumen sampling headroom. Currently, it’s very easy to reach the maximum allowed by Lumen. It would be interesting to be able to enhance it further, not only by increasing the octahedron resolution and reducing the jittering size, but also by increasing the number of samples per pixel, for example. Useful for cinematic shoots.
Reduce dependency on temporal accumulation. As I have tested many times and also read, Lumen is not capable of reaching high refresh rates (but it can maintain above 60fps, which is what matters). To make temporal accumulation less noticeable, high refresh rates are needed, the higher, the better, but Lumen can’t reach them. “The Lumen paradox”.
My understanding of the matter was always that emissive objects could be excluded from lumen, but screen traces meant there would be a large discontinuity between on-and-off screen geo. I don’t know if it’s fixed yet, but I feel like I saw something on managing that in another thread, could be mistaken.
I’m excited to see this happen as well, because on my machine (4070), especially for offline purposes, I have the headroom to push lumen significantly further than it can go. Of course, as Daniel Wright said, they are primarily targeting next-gen consoles, which unfortunately puts a pretty strong ceiling in place for quality barring innovations like neural denoising and the like. Nonetheless, I can’t wait for the team to have time to address it.
Apparently (if I’m not wrong), you can exclude them from RT traces with one of the commented tricks, but Screen Traces will be still there, causing even more noisy patches. (And disabling all global screen traces shouldn’t be an option).
You’re being a hypocrite. You end up ranting about me, telling me what to do when I already clearly stated that UE is miles ahead of anything publicly made.
Talking about how my stuff is unrelated(I have detailed post explaining why it is) to lumen yet you abuse the thread in the same way to tell me off?
I have to read you talking down on the engine and the developers.
Yeah? So what? I’m allowed to complain and criticize the engine for it’s flaws.
There’s not really another way to push forward and suggest fixes which I already have and constantly give.
As a user of UE, it’s my job to point out major issues that can cause quality slippery slopes in the workflow. As engine programmer(such as th lumen team), it’s their job to figure out how to fix major problems pointed out. Their knowledge, their responsibly.
If anyone else has a problem with me, PM me instead of being a hypocrite.
It’s extremely simple, if you attack me here on this thread, I defend myself here on this thread.
1+1=2.
Maybe translucent but emissive could do the trick for you since translucent materials dont show up in the lumen scene and since 5.3 also shouldn’t appear in screentraces anymore.
Using translucency will work in most cases, so long as you are willing to break the emissive part off into its own mesh. Trying to enable translucency on the whole mesh (even non-emissive parts) is just asking for problems (performance, sorting, shadowcasting…)
Unfortunately the last time I brought this up, this was the current stance.
So I don’t think we’ll see a per anything switch to stop traces that can’t exploit data already present in the gbuffer - like we’ve seen now with translucency.
A per shading model toggle would honestly be good enough for most cases I think.
But there are also some cases where regular, opaque geometry has a large mismatch between its screen trace vs lumen scene representation. I’m not sure what existing data within the opaque model could be readily used to determine whether to screen trace or not.
An example of this is when using certain features that don’t properly render into the surface cache. Distance field based effects, or camera vector based material effects don’t work in the lumen scene, but will work fine in the screen trace. This can lead to jarring differences in material appearance that are exposed at points where trace coverage ends. In these cases I’d want the option to skip the screen trace.
I just haven’t thought of a common thread that can isolate them without using that extra bit.
I’m surprised to see you say this honestly. I guess it depends on what you’re using the camera vector for, but screen traces fail horribly if you’re using the camera vector for any sort of parallax effect (presumably because Lumen’s screen traces are just tracing the depth buffer)
Raytraced hit lighting produces the correct result while screen traces don’t:
I still feel like it could be a good idea to include gi/reflection screen traces toggles in the post process volume, so that they can be disabled regionally. I suppose this can be done already in blueprint though so… meh
Also still hoping Substrate might offer some more flexibility about where screen traces are skipped.
No problem with sharing your opinion, that’s what this thread is for. But you are flooding this thread with useless information and make everyone else’s life more difficult because we (and the devs) don’t have much time to read through all the comments and filter out the useful informations. Many, many users asked you politely to stop spamming this thread, yet you keep repeating your opinion. This thread is to report bugs and issues to the developers, not for meaningless debates, comparisons and etc, which does not help their work.
Since the surface cache computes the materials from fixed camera angles / cards, in this example of a fresnel we can see it has blended together a capture from every side, resulting in the fresnel being totally broken.
For a screen trace, the fuller the coverage, the more accurately it will reproduce the effect - But it will still have a jarring discontinuity at the transition point regardless of method.
On a material like this, I’d ideally want to use hit lighting and skip the trace altogether.
But without hwrt I think I’d rather keep the screen trace, since it will at least be accurate sometimes where as the surface cache will be accurate never.
So the question becomes, if I have a scene with POM or some other effect that doesn’t play nice with traces but I don’t want to disable them entirely for that shading model - what can act as my switch?
The only thing I can come up with is that the custom stencil could… while it’s widely used for other stuff, it would be the least disruptive place I can think of.
You could have a particular bit or range to act as a mask to skip traces, and the rest of the stencil bits could work as normal.
People who need the entire range of the stencil buffer are probably a smaller edge case than screen trace artifacts.
It could be as simple as a checkbox and int range to select the bits.
“Skip screen traces on custom stencil value/range [x-y]”
Hi all, I have a question for anyone interested and for @Daniel_Wright ,
Why so much effort for current gen consoles, when they will become obsolete in not much time? (And not a lot of games will be released with UE5 before that date?). I think nobody would care about not using Lumen nor Nanite in current-gen consoles. Even more if using them requires some tradeoffs that users don’t want.
I have also seen comments pointing (in a well documented way) something like “this won’t be possible to Lumen because of -it’s nature-”. So, I wonder: was Lumen conceived with the current gen consoles as the main objetive? Was Lumen conceived as an scalable engine, to be able to evolve and cover the needs of trully next gen consoles and future PCs, in 5 years? Or it is already limited since it’s birth, and the solution/engine will be a new one?
Mid-gen refreshes are coming soon, focusing on current gen consoles is focusing on the most common PC GPUs. And the way lumen is setup, it’s swappable between different solutions behind the scenes.
We’re only 3 years since release of the PS5. The PS4 was sold for 7 years, and now - 10 years later - we’re still seeing cross gen launches, because the PS4 market share is still more than twice the size of the PS5.
In other words, it’s a smart bet to invest in technology that works well on current gen hardware, because there is a good chance that it’s going to be relevant for a long while still.
They quickly become obsolete from a technical perspective, but not from a market perspective.
