Oh plz. give us a beast mode 
something for translucency too. The hardware will catch up someday 
Thanks for all the work. The progress in unreal is fkn amazing to watch.
2 Likes
The hardware will catch up someday
The hardware is already here and so is the software.
Studio are literally disbanding due to how little players can actually play their unperformant blurry games.
If you need to render just dig into Lumen’s Cvars or Path trace.
Daniel, glad to hear you guys targeting consoles, since GPU wise it’s closer to the 2080 raster wise and that’s 4k via 20 series power/price scale.
lumen with rtx (raytracing gi and reflection)
lumen without rtx (without raytracing gi and reflection)
no, both are lumen and dynamic lighting
ray tracing in disabled on the left one
but enabled on the right one
You mean hardware(HWRT) Lumen vs software (SWRT) Lumen?
EDIT, Also I thought Lumen doesn’t work in DX11?
RTX is Nvidia’s branding for their GPU series.
yes I mean that!
Lumen working with DX11
There are subtle but more-correct variations between the two.
Look at the scene with the leather couch on the left and the light coming in from the right-side window, shining on the floor in front of the couch. The couch itself has much better detail, look where the light touches it at the front of the seat-cushion. As well the lighting on the floor is less-harsh, softer borders as you might expect.
Subtle, but the differences are there.
Software lumen works with DX11
2 Likes
I’ll add to that: RTXGI is sort of ambiguous at this point, as to my knowledge it refers to NVIDIA’s homemade GI solution (which NVRTX features). TMI it’s defined by a reSTIR-based integrator and DLSS 3.5 in the newest version (correct me if I’m wrong). RTX is a brand segment of GPUs that also refer to their supported ray-tracing features, but not all ray-tracing is RTX (AMD and intel have their own solutions), and there’s the afformentioned software ray-tracing.
So, I think @Farshid your comparison is somewhat ambiguously labeled; I believe what you’re refering to is SWRT vs. HWRT in lumen? In which case, differences will look most stark in areas of heavy specular reflection, not as much dull reflection and diffuse lighting as your scene largely possesses.
1 Like
(post deleted by author)
2 Likes
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?
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.
2 Likes
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.
1 Like
(post deleted by author)
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.
2 Likes
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.
Turning back to the feedback purpose,
Hi @Daniel_Wright !
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”.
Thank you and best regards!
1 Like
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.
1 Like