MegaLights feedback thread

Development Rendering
, ,
203

No. Here is a shadow edge at native 4k with no AA: Super sharp. Here are two lights with overlapping shadows. Shadows are so sharp that there is visible stairstepping.

image
image517×531 16.3 KB

I reckon your issue is elsewhere if you are dealing with noise in this case.

Hopefully, because I personally don’t think that nanite foliage is in a place where that is a viable solution for many projects. But do you see what I mean that your feedback is charged with negativity and baggage?

You could just say, “My projects are not able to use nanite for foliage, so full alpha masking support is important for me to want to adopt this feature.”

Surely you see the difference. The bitterness, complaining, etc are not required or particularly welcome. It makes reading such posts exhausting, even when I think you’re right.

P.S. again for brevity

If you think that treating the devs and community members with respect is “coddling” you are really only supporting my point about needing to have some self-reflection. Sure - People are being paid to work on the engine, but that doesn’t mean they are being paid to cater to you specifically. (I know it’s not just you asking, that’s not the point)

I’m not saying don’t ask for what you want - I’m asking you to think about how you ask for it while we are still afforded the privilege of participating in these communities. Epic does not need to entertain anyone’s idea of what is a top priority. We are not in a position to blame anyone because we are not fully in the know about the internal priorities that are set for each release. When you call the work lazy and/or incompetent because it isn’t what you wanted (from the tool we are being provided for free*) you risk being perceived as entitled and that negativity can devalue what positive contributions your efforts may potentially bring.

And frankly I am being generous when I say contributions, as it is much easier to complain than actually contribute.

I am pretty sure that the engineers are not oblivious to image and motion clarity, are aware of your feedback, and if you feel ignored, again, self-reflection may reveal at least part of why Epic might not be eager to interact with your content.

I’m off to enjoy my NYE now - hope everyone here does too.

4 Likes
204

That’s wrong.

Just an advice: you should ALWAYS (if applicable) add a screenshot (of actual if cases, preferably) to your affirmations and questions, to be taken seriously and not as a beginner. You are becoming “popular”, but maybe not in the sense or direction you want. I am really friendly advising this to you.

205

(post deleted by author)

206

That’s wrong.

No it’s not, you all keep posting meaningless screenshots when this is a temporal issue, which means it can only be seen in motion.

MegaLights shadow noise, on a 12GB 3060.
There is no need to lie. People already know this engine is a noisy mess.

209

There’s always the forward renderer, Lightmapped GI still looks fantastic, it’s so fast you can run it on a phone, and it supports MSAA.

2 Likes
210

(post deleted by author)

1 Like
211

Ah I see… you’ve disabled the temporal accumulation buffer for MegaLights with r.MegaLights.Temporal ?

MegaLights is a fancy marketing name for “stochastic shadowing.”

Stochastic means randomly sampled.
The idea behind stochastic sampling is that while any individual spatial sample is wrong (at least part of the time), multiple samples accumulated over time converge towards being correct. This will result in a roughly 1 pixel border where noise can occur as the ray sometimes hits the light but sometimes doesn’t on a frame by frame basis.

Even if you have TAA off in your project, you can use the temporal buffer for MegaLights. The ability to turn it off is probably for debugging purposes, and not intended to be used like that.

But if you do, and want to make it temporally stable, the command r.MegaLights.FixedStateFrameIndex set to 0 will prevent the noise from moving each frame, although camera movies will still cause shifting as the noise is not projected in world space. With supersampling this shifting can be made invisible by making it subpixel. So perhaps when you finally get around to adding some form of SSAA to the engine this can be solved.

You are still working on implementing a new AA algorithm, right?

With the MegaLights temporal buffer turned on, even with TAA off, the noise all but completely eliminated. I’ll admit that it is a tiny bit - almost imperceptibly - less sharp than standard RT, and that there is a 1 pixel edge where sometimes noise can be visible. Although once you add texture, normal maps, etc. even this essential disappears in the final image.

Asking MegaLights to be completely temporally independent entirely misunderstands the technology. The innovation IS the stochastics (aka noise) so if you have a problem with a tiny amount of edge noise (which is perfectly valid opinion, although I think most would disagree that it is an unacceptable compromise for the performance gain) then switch on standard RT and pay the price for non-stochastic quality or use CSM. This feature just might not be for you.

I’m sure that it’ll continue to be improved, even in the noise department… But asking for 0 noise without any temporal accumulation is probably asking for a mathematical impossibility. At least without supersampling I guess.

There is no need to lie. People already know this engine is a noisy mess.

Again proving it is impossible for you to provide feedback without being negative.

3 Likes
212

he did not disable anything. he’s just reluctant to use taa. i asked if it fixes it and he choose to go brain dead and report my post again, for no reason.

details

stubborn. immature. can’t take critique, either. i’m not biased and tried to help his case, but he still behaves like an idiot. this has to publicly said. cause it’s true. this stupid antics will get nobody anywhere. it’s just negative vibes, nobody needs. yes.

you can actually exaggerate the effect using lower screenpercentage. and… taa completely removes the artefact. just gotta use it. so easy.

it’s still a beta feature, but it’s working. argueably there shouldn’t be any noise when sampling a 0 source radius lamp, but there is a fix for the noise. TAA. i guess it’s using the same temporal pattern to remove the artefact. systems working together. just gotta enable all of them. you can look at it and say it’s blurry, but infact it looks similar to traditional shadow mapping, with the benefit of more light amounts and complexity.

@Krzysztof.N maybe you should build a version without temporal accumulation, straight all gather, just for theKJ so he can watch the slideshow he most likely wants. tbh

213

Ah I see… you’ve disabled the temporal accumulation buffer for MegaLights with r.MegaLights.Temporal ?

No, all defaults.

I understand stochastics, but many can accumulate without TAA to average out the noise.

command r.MegaLights.FixedStateFrameIndex set to 0

That’s actually pretty good. There seems to be a bug tho the prevents toggling(wanted to compare).

You are still working on implementing a new AA algorithm, right?

Several others are, SMAA was just pluginized and another one in development.

Asking MegaLights to be completely temporally independent

And I’m not. A lot of people have no idea what I advocate for. Better TAA and better effects have to be developed, you can’t have one or the other. Poor effects can’t be denoised by competent TAA. The noise is a major issue and it’s interesting to see how the lines don’t end up as straight as RT shadows.

214

Weird, at 100% screen scale and default settings I seem to have less noise. Are you at 100% screen scale? And what is your monitors pixel density?

They can and do accumulate without TAA. The temporal filter is independent of TAA. But filtering must be either spatial, temporal or both otherwise there will be noise.

Do you have the SMAA plugin? I’d be interested to see if it can detect and spatially super sample the edge to compensate for any lack of temporal super sampling.

215

that’s worth a dive into the engine code, to figure it out.

i would rather guess tho. it’s probably path tracing paradigm. i know how pathtracing works. you should maybe watch a good video on that subject. they surely are running shortcuts for realtime application.

basicly per pixel you have a surface normal and a in this case maybe circle of diffusion to get samples spread for soft shadow accumulation.

you shoot a couple of rays in a hemisphere. depending on where on the diffusion circle the pixel is you may get whacky results. in path tracing you shoot at all or the important the lights and determine the shadow mask.

or you would i guess raymarch screentraces. if you hit geometry in range you are in shadow, compute gi from radiance or surface cache, do the surface shader math and you have a shadow pixel color.

if you you don’t hit geometry in range you have a lit pixel, accumulate light from a local light cache or gi, do importance “sampling” and maybe check the light radius to compute a light guiding vector you can store in the temporal history. do surface shader and you have a lit pixel color.

tepporality is time and motion. as long as you have continuous motion vector history every pixel is just a data asset with a reference to the last screen position of the pixel, maybe the guiding vector and maybe some other data like ids and stuff you need for recycling, to not recompute the whole pathtrace every frame. you run just a simplified update with maybe one ray per pixel. cause… compute budget.

i’d guess this is also where the disocclusion errors happen. when a pixel is occluded you loose the temporal history reference and have to recompute all the pixel data in that case the same pixel pops back up later. this is an apparent issue with dithered materials. cause the occlusion makes the motion history noisy. the smeary hair shader. a lot of new titles have those. yes.

either way it’s just speculative visualizaion. ill bit of engine graphics programming.

216

Then if we contrast that with standard RT shadows…

With standard RT shadows, you can simply shoot one ray from a pixel towards each light source within radius (if you want sharp shadows, soft shadows are another story). No cones or random sampling needed. We know exactly where the pixel is and exactly where the light is.

This is why they can be perfectly sharp and noise free with 0 temporal accumulation. But it’s also why RT shadows scale poorly with multiple lights. You need to trace at least one ray per pixel, per light within radius.

As a result, I believe the cost for each subsequent light after the first is relatively linear.

Changing this approach is what allows MegaLights to have basically fixed cost regardless of the number of lights.

2 Likes
217

RT directional lights actually do handle it now, something like raytracing.shadows.injectraytracedlighting. Performance obviously isn’t good, but it works great for cinematics.

1 Like
218

okay. i’m currently not on the main branch, tho. 5.5.1 doesn’t have that switch. it still has the old “r.VolumetricFog.InjectRaytracedLights” one. directional worked before, but is currently wip. np. : )

1 Like
219

I have a lot of problems with megalighs performance. In editor everything looks great but when I run game, performance goes down a lot. Without megalight I have 120 fps, when I enable it during the gameplay it goes down to <60fps.

All performance is eaten by RayTracing_FinishGatherInstances - 5ms, just wth?

220

Are you using nanite proxy geometry, or full-fat meshes? And instances is interesting, I was under the impression that MegaLights didn’t work with ISMs yet in 5.5?

221

I’m loading some parts of level by LoadLevelInstance, looks like megalights have problem with this. I’m adding few levels on the main level borders to have some background, looks like no matter what is on this level it cause a big performance issue when combined with Megalighs.

I’m using a lot of HISM and ISM and so far I haven’t seen any issues.

222

Have you tried loading the levels in a different way, just for testing? (Or always loaded)

I’m using a lot of Packed Level Actors (lot of instances) and don’t seem to cause problems.

223

As far as I know it is impossible to load the same level multiple time in any different way.

224

Multiple times?

I think I’m not understanding you.

I’m talking about getting those levels always loaded from the beginning, not loading them from any blueprint. Just placed in the main level.