MegaLights feedback thread

[Miguel1900]

@BananableOffense

@Miguel1900

PS: I don’t know if this makes sense for any real game, with tons of moving elements, then

This is exactly why a significant number of modern raytracing titles have animated character’s reflections in screen space only.

Going back to my earlier feedback, we probably need a way to flag shadow casters as screen space shadowing only. Won’t work for every case but it should be ideal for certain things like foliage and ground scatter which often needs to move and are small enough to be represented well enough in screen space only.

In your case, I simply would not have the fan blade casting RT shadows. If you need the appearance of a light source shining through a fan to cast a moving shadow, I would try using a light function. I think this should eliminate the overhead of updating the BVH. Then you can have a mask in the shape of the fan blade.

I would probably make a distance field alpha mask, as then you should easily be able to fake soft shadows based on distance by controlling the range of a smooth step.

Perhaps you can switch the closest fan to true RT shadows and have light function proxies for farther ones if you really need it.

Thank you @BananableOffense ,

I get your point and it could work for small objects, yeah, however, in this case, I just added the fans to add a stunning shadowing effect in the scene. Your workaround ideas could work, thank you, but are a little hard to implement. In addition I have noticed some non-desired results with light functions in MegaLights (something like too noise or blurryness). But if it’s the only way… maybe I will try it.

@Krzysztof.N

There shouldn’t be anything in MegaLights what makes it slower when you start rotating static meshes.

If those would be meshes with WPO or skinning then you would incur extra BLAS build costs, but 10 simple meshes shouldn’t cost much.

My guess is that this is due to some legacy moveable object interaction tracking per light. Try to disable it with r.Visibility.LocalLightPrimitiveInteraction 0. It’s not needed for MegaLights, but we run out of time to handle it properly. Through this cost would also incur with VSM.

Otherwise it would be best if you would disable async compute using r.RDG.AsyncCompute 0 and then profile both cases using insights or something in order to figure out what gets more expensive.

Thank you @Krzysztof.N ,

@BananableOffense , according to @Krzysztof.N 's comments, I shouldn’t need to do that workaround, in this case.

However, @Krzysztof.N 's cvars doesn’t seem to have an effect here.

I’m not sure, but I think the moving fans are having a big performance impact, even if it shouldn’t, according to @Krzysztof.N 's comment.

Please, could you all test my demo scene to confirm it, at least? Or I am missunderstanding something? Hit Play and notice the performance changes every 5 seconds, when fans stop/start:

Moving_Megalights.zip

Thank you!