Deleted
The problem with your posts is that you don’t really seem to have anything to say other than “Make FPS go up. No upscale. No TAA.”
Yet you post these screeds like you’re hitting Epic with some hard truths they need to hear and you’re the only one with the courage to tell them, but in reality you’re just stating the obvious. Everybody wants better performance without sacrificing quality. Literally everybody. Which is why Lumen has continued to make steady improvements to both quality and performance since early access to this day and no doubt that trend will continue in the future, with or without your daily diatribes.
In any case, you will do as you please. I’m done with this.
5 Likes
TAA and temporal AA methods are cancerous, and should never forced on people.
The lumen team needs to add motion vectors to their Lumen temporal accumulations. That way we don’t have to rely on TAA or TSR to fix lumens flickering issues.
Moving meshes have serious issues when you raise the temporal accumulation too much(to stop it from flickering).
This topic is becoming way too negative in my opinion.
How about we stop turning this into a toxic landfill that buries all the useful information in here that is still valid today?
3 Likes
Tbh, the last comment I made was pretty relevant.
Lumen has poor lighting effects for Skeletal Mesh.
Lumen’s documentation seems to indicate that it does not support Skeletal Mesh.
Does Unreal Engine have plans to improve it? Currently, most animation projects using Unreal Engine use Skeletal Mesh for character animation import.
Lumen is very important to animation projects, hope to get relevant support as soon as possible.
Could you guys just leave and fight it out somewhere else? This is a feedback thread, developers are looking for useful informations here, not for your debates. Thank you.
2 Likes
Lumen supports skeletal meshes, the surface cache and mesh distance fields do not, which means they can’t bounce light from off-screen and in software raytracing mode they will also not be visible in off-screen reflections.
In order to get the best results from Skeletal Meshes in Lumen you should use hardware raytracing (with hit lighting for reflections) in direct lighting if they are going to be visible in reflections.
3 Likes
The devs mentioned improved skeletal mesh support being on the docket at some point, but there’s no timeline on that.
I wonder if/how the capsule shadow system would talk to lumen.
1 Like
I have seen that on other things. If you go to the Lumen’s 5.3 normal-geo visualization.
That same area with be highlighted green.
Only with lumen enabled?
honestly i havent tried turning it off,
is there a chance that you know why anti aliasing isnt working on metahumans also, there appear to be some black boxes on top of them them
I would first turn it off and test, then you can know if it’s lumen or not. Also try changing the bloom method from standard to convolution or vice-versa, it seems like bloom can break metahumans for reasons I don’t understand.
2 Likes
This video is set to private, no besides you can watch it that way 
1 Like
We do have caustics via the PT, but if I had to guess it’s because the engineers are handling other features first, as caustics are an incredible phenomenon but probably not as essential to most users as simply getting lumen to run better, or have less noisy GI.
Nvidia does, for the record, have real-time caustics in Unreal. I did a pretty big review of their tech a big ago, and my bottom line is that it’s a technical marvel held back by poor UI (although that has been partly rectified to my knowledge).
There is a presentation about Lumen from SIGGRAPH 2021 :
" Radiance Caching for Real-Time Global Illumination"
and at the end shows a few pictures. Most are made with “half a ray per pixels” but there are a few with 2 rays per pixel for a much higher quality.
First picture attached is with half a ray and the second is with 2 rays per pixels.
What are the cvars or the controls in Lumen to change that magical “rays per pixel” ?
3 Likes
Would also be interested in that one.
This is, thankfully, pretty easy to answer.
My understanding is that .5 RPP and 2 RPP are settings conjured up by default by switching from high to epic. If you want the specific lumen scalability CVars, Epic already has a page setup for lumen performance optimization:
That being said, the concept of ‘RPP’ is a little meaningless with lumen GI. They aren’t actually tracing a ray per a given pixel for diffuse lighting; instead, it’s referring to the # of rays shot per screen probe, which is then interpolated to the Gbuffer for diffuse lighting. Just a bit of technical minutiae, but still.
It seemed like it would be maybe an undocumented and easy way to get past the known methods of improving quality. Even if those 2 rays per pixel seemed like it would be very high quality, when rendering with MRQ you don’t care how slow it is, you just want to increase the quality as high as possible, or until the render starts to resemble the path tracer.
“the concept of ‘RPP’ is a little meaningless with lumen GI” ? But the guy from the video used those terms, plus he was also talking about Lumen.
And that said, I’m not sure which parameter from the " Lumen Performance Guide" would be the equivalent to “rays per pixel”.