Hi @JaroMast,
Can you share a small project that reproduces this issue? Or if not possible could you provide more info regarding the level where you are seeing this issue:
How many actors are there in the level?
How many ISM or HISM actors?
How many instances per ISM/HISM?
Are the ISM using Nanite meshes?
How many skeletal meshes?
Does the time spent in RayTracing_FinishGatherInstances change significantly between editor and running the game? If so, do you have blueprints or other logic that only spawns instances when running the game and not in editor?
When the fans are enabled, there’s 13ms overhead on render thread which can be avoided by using r.Visibility.LocalLightPrimitiveInteraction 0.
There’s also about 15ms overhead on game thread, executing the tick of the fan actors (which is not MegaLights related). Of those 15ms, ~5ms is caused by UpdateOverlaps() which can be avoided by disabling Generate Overlap Events or collision altogether on the relevant components.
CreateLightPrimitiveInteractions overhead which is avoided using r.Visibility.LocalLightPrimitiveInteraction 0:
Thank you very much for your time testing and the detailed insights!! So glad.
Following it, I have been able to improve the performance a little and now it’s loosing around ~30% performance when spinning, instead of ~50%. I have been making some additional tests too, and noticed if enabling Nanite in the spinning meshes would improve the performance quite a bit. Additionally, if completely disabling collisions on those spinning meshes, performance wouldn’t drop and would maintain at 100%.
I know this is not directly related to ML, but anyone knows if this should be normal?: many spinning actors would heavily hit the performance due to their collisions (even if just Query, no Physics).
@TiagoCostaUE , I also noticed when using RT shadows the performance won’t drop even with collisions enabled. I think ML relies in RT shadows, right? Couldn’t them benefits from this RT shadows ‘feature’?
Noticed something regarding ML + volumetric fog (enabled with r.MegaLights.Volume 1)
In some situations, it’s like “projecting” a shadow (a silhouette) over the fog, from a point where there is no a light. And it varies depending on the angle:
Does using r.MegaLights.Volume.HZBOcclusionTest=0 prevent that issue?
I fixed a related bug last week in ue5-main and will try to get it integrated into a 5.5 hotfix. Let me know if you are able to manually integrate and test that change locally and whether it fixes the issue.
Otherwise, are you able to reproduce this issue in a project that you could share with us for further investigation?
Also tested in 5.6 from the 12th and the issue was there too, if I’m not wrong. I will try to isolate the issue in a project and share it with you.
PS off topic: in main branch also noticed Lumen reflections (spotted in a water layer material) being too bright and/or contrasted, not corresponding with the Screen Traces part. In 5.5 was working fine. Will try to include it in that project too, but next week probably, as I’m releasing my game this one! O.o
Is your project overriding r.VolumetricFog.GridPixelSize with a value that is not a power-of-2?
We have just found a bug that causes artifacts in fog when using such values and are working on a fix.
Great deduction capabilities. For the moment I have disabled it with the cvars we commented before (volume and/or occlusion) without visual impact. In which situation could I see a visual difference, in the case this bug would exist?
In the meanwhile, can we say this is the technologically most avanced game in the world because of being, maybe, the world’s first game using MegaLights + all UE rendering techs?
From the conversation in the lumen thread, Megalights currently does not support translucency. Is Megalight translucency expected to be supported in UE 5.6? Colored shadows as well, for that matter?
“low poly” ism foliage on the board. will figure how to spam it nicely and efficient. there’s a lil threshold radius around mega point lamps (pic 03) but… it’s fixable with a rebalance of the ambient light. this shot is a completely stage 0 static test, anyway. baked gi and volumes and all. hmm…
@Aresias i already confirmed it. disabling taa will show you the noise. even more so on lower render resolution. and… i posted the solution. yes… at this point taa has to be used and in a game using megalights should be enforced to antialias the stochastic pattern of megalights. it’s just how it works.
upscaling has nothing todo with it. unless upscaling and antialiasing are combined in one pass, which is what tsr does (?).
@TheKJ why you fall for this “clown” jebait at this point? as mentioned, i confirmed it. chill
You can set r.ScreenPercentage to 100 too with FSR 1.0 but i can’t try it since the ported plugin version doesn’t support 5.5.
But you may be right i’m not sure if it can do AA if set to 100%, you can with FSR2/3 but maybe not with FSR 1.0
Anyway SMAA can only detect L, U and Z shape and blur the surrounding pixels it also destroy the UI by adding rounding edges to every sharp edges like fonts if done just before the final image, i was using SMAA injector back in the days.
For Megalights why i don’t reproduce for static objects ?
I do have more noise with the moving character but the amount of noise is acceptable.
Have a look at all my settings in this new video.
There are many settings to set correctly to force rendering at 100% resolution and without AA.
your video is in 4k obviously. way higher pixel density for your eyeballs. if i download it and watch it native (cropped) i can still spot the artefacts on the shadow edges.
Of course, if you zoom in at 1000%, you’ll see that there’s noise.
My point is the noise is very low, not like the other videos you are all showing.
If there was a shadow/light algorithm that didn’t produce artefacts and that adapted well to multiple lights and adapt instantly to moving lights, all the other algorithms would have been abandoned a long time ago.
Almost all the algorithms in existence today are the result of research carried out decades ago (but slightly adapted for rendering use cases) and which are just being applied today in real time because we now have the compute power to do it.
The artefacts errors to me doesn’t look higher than the lack of AA that produces stairs effect errors for straight diagonal lines.
This is like the Nyquist–Shannon sampling theorem, if you want the shadow to look perfectly straight you would need to already oversample the shadow for it to look good.
i don’t zoom in. i’m not one of those an*l guys. the average game with real colors and textures (aka my prototype) does not expose that. in harsh lighting environments it’s kinda noticable. nothing to cry about tho, tbh. yes.
just to prove the point… your video cropped to 1080p pixels. you should download and watch it in fullscreen to see what i would see on my screen. a lil bit of edge noise on static mesh shadows. hmm…
