Hi,
I saw a cool trick on the state of Unreal Engine presentation. The developers of Hexworks using it on their game Lords of the Fallen. This seems very usefull and tried the Lumen_CARD_Replace custom node but didnt seem to work for me in 5.1. Not sure what im doing wrong. Need help to get this working. Thanks.
The code in your custom node has the inputs named “InputA” and “InputB” but your node is set up with the names “Lumen” and “Default”. You either need to change the names in the code to match the node, or vice versa.
The input “Lumen” and “Default” means nothing to the code as it currently is written.
Worth mentioning this approach basically doesn’t work unless you disable screen traces.
Disabling emissive doesn’t really work unless you also disable traces like you suggest. But I think enabling emissive on an otherwise invisible object should be just fine, since there would be nothing on screen to trace anyway.
Thanks, I will try it at once I get the chance !
Thanks for the tip.
I dont want to disable emissive, just have an invisible emissive sphere that can be used to light certain areas. Will my approach work ?
It works… if you disable screen traces.
If you just fix your custom node and give it a try you’ll understand quickly why this is.
Ok, thanks! On holiday, but excited to try it out when I get back.
Another problem with this approach is that the mesh will still be visible in reflections, since Lumen reflections just return whatever it finds in the Lumen scene.
Hehe, ok. When they explained this in the state of unreal where my reference is from it seemed like such an elegant solution…maybe not.
I found screen tracing to cause inconsistencies when using a small light source, but it didn’t seem to cause any noticeable issues with a larger light sources like the one shown above (~1 meter diameter I think) with screen tracing on and still looking great. Disabling screen tracing did make the smaller light source more consistent. Much to my surprise, this setup did not cause the light source to be visible in reflections.
(here it is with the opacity set to 1 for reference)
However, it only really provided satisfactory results with hardware raytracing enabled, in my opinion. Software RT looked really bad and inconsistent. Also be sure to enable “emissive light source” on the mesh otherwise Lumen will quickly cull it.
Huh, on further testing, I don’t seem to need the lumen card replace custom node at all. Even when the object is totally masked it still seems to add the emission. I also noticed I got better results when the material is set to two-sided, especially when screen tracing was on - even when the back-faces of the material weren’t emissive. Not really sure why.
That’s interesting, are you sure reflection screen traces weren’t just masking it?
Screen traces can be disabled separately for Reflections and ScreenProbeGather.
Seems this happens when you use hardware raytracing with hit lighting for reflections. Very interesting.
I always had problems with self-shadowing with screen traces enabled regardless of the size of the emissive source. 1 meter sphere was used here for testing. Maybe it’s just less noticeable in exterior lighting conditions.
Seems you’re right. Software RT can show the sphere in the reflections but hardware RT does not.
You inspired me to finally dig into this. I noticed the shadows align to a grid which made me realize it must have to do with Lumens voxel size.
Specifically, it looks like its a factor of the distance between the surface and the Lumen Radiance Cache grid resolution. Increasing the resolution will allow the surface to get closer before you have a miss, and also visibly decreases the size of the grid tile. Below you can see 32, 48 (default size) and 64 sized grids. (larger resolution = finer grid)
r.Lumen.ScreenProbeGather.RadianceCache.GridResolution
In my simple test scene it actually didn’t seem to effect performance at all. Give it a shot - might be worth cranking up in certain interior spaces especially.
It seems it actually even brings Software RT emissive into the realm of usability, if you can get past the emitter being visible in the reflection.
@BenVlodgi posted this in another thread and thought it would be relevant here:
Didn’t notice this in the release notes. It still seems to require disabling screen traces to get decent results, but at least you don’t have to set up a material switch for the Lumen scene which makes it easier to work with since you can actually see what you’re doing.
Saw that the other day too, meant to test it out and post it here but was working on other stuff. Guess you saved me the trouble. Shame it doesn’t solve the screen tracing limitations though.
