Been playing around with injecting emissive materials into the RT Global Illumination lighting environment. Big drawbacks are:
Tommy.
And this is it without a the denoiser…
Tommy.
Progress! Okay… looks like I have it correctly sampling the emissive geometry, using a section of the pathtracing logic. Now, you don’t need to use any lights in your scene to get emissive GI 
Looks like I have something here (found a good technique in the pathtracing code going to use it)… Cornell box time!! I’m going to do a pull request on this and see what Epic thinks 
And finally… the reflections demo, all lights removed. Leaving only the emissive geometry in the scene (the tube lighting):
Looks great! Don’t know why emissive isn’t already in RTGI, seems an obvious first thing to read from.
Ah thanks Frenetic Pony! Yeah it works quite well. I grabbed a section of the pathtracing code for sample emissive contribution. For dark scenes, you have to boost the Samples per pixel for GI to reduce noise… but it looks fantastic and it is in glorious real-time, so well worth it. If you make the lights flicker, the scene correctly responds 
I’m currently integrating my changes into my local main branch of next UE4. I’ll post my pull request to Epic and post it here too for people to experiment with. It’ll be enabled and disabled with:
r.RayTracing.GlobalIllumination.EvaluateEmissiveMaterials (0 for disabled, 1 for enabled)
then
r.RayTracing.GlobalIllumination.SamplesPerPixel (for quality)
Tommy.
Okay it is a pull request for Master now, so 4.24 if Epic like it. If you are interested in integrating it into your own build, you can find the pull request here:
https://github.com/EpicGames/UnrealEngine/pull/6193
Good luck!
Tommy.
SCREECHES LIKE A HARPY
YES YES YES YES YES! A thousand times YES!
Setting enthusiasm aside, what kind of performance are you getting and on what hardware? I’m having a hell of a time with Unreal Engine getting acceptable performance with RTGI on a 2070 MaxQ.
Hey Aeries,
It is performant for me on a GeForce RTX 2070 on a ROG laptop (but noisy at default samples per pixel GI). Mileage will vary with scene size/complexity/lighting setup and samples per pixel of your GI. Note that the emissive material light sources are noisy by nature, but with the right denoiser (not included 
), I believe, can yield get good results. This scene for example runs 60fps on my GeForce RTX 2070, at 30 samples per pixel GI, but the scene is small.
Default Samples (60fps):
30 Samples Per Pixel(60fps):
I guess to sum up, I would say that the addition of this won’t hit your performance as much as people would expect, but dark scenes will be noisy.
Tommy.
This looks so good! Good job!
@TommyBear I run this year’s MSI GS65 Stealth laptop so this ought to be a neat comparison when I pull the code! Thanks for putting this together! THIS is the dream and imo, one of Raytracing’s truly most powerful features. I’m legit shocked this was omitted from the baseline raytracing features when Epic added it.
You rock.
Very exciting! Would love to see some video examples to get a sense of the noise. Hopefully they will accept the pull request…
Also just realized that:
r.Raytracing.GlobalIllumination.ScreenPercentage defaults to 50 (50% of screen),
setting this to 100 also helps with noise, but impacts performance obviously.
Hey @TommyBear ! I’ve just now noticed Epic’s reply on your Pull Request, and I must say, I’m really disheartened.
The project I’m involved in relies hugely on emissive lighting support on geometry, baked using GPU Lightmass, and any migration over to DXR would require this same functionality.
I tested your code change here, and it just worked! And worked very well indeed. There was negligible impact on adding a new geometry-based light source.
I just wanted to say thanks for your efforts on this (should-be default in my opinion) feature.
I’m having difficulty in determining what ‘noise generator’ means, have you got any insight into what Epic meant in their reply?
GI Noise is relatively bad in the current state of DXR implementation in UE4, but I don’t know how that would relate specifically to your approach, which simply adds a new light source, it doesn’t create any noise that doesn’t exist with point/spot lights. Unless I’m misunderstanding something?
Cheers!
@TommyBear Hey, thanks for your help the other day! I got this up and running and it produced the best results out of Unreal Engine’s DXR implementation that I’ve seen to date, with the only noise in the scene being the direct result of the Engine’s work-in-progress denoiser. I have no idea the real reason behind Epic’s denial of your pull request (I found their explanation unconvincing) but I hope they get back to you with better clarity than we saw in the comment.
We’re all rooting for you! Great work!
Hey guys, I have read the comment from the dev and the meaning of “noise generator” there is that the implementation made was introducing “more noise”. I would need to look at the whole code to understand better if that is indeed an impact, but hey that won’t stop us to inject that code on a built from source engine and enjoy it. Since there are so many things still at work by Epic in relation to raytracing there is a chance this “more noise” is appearing on a code not yet submitted to GitHub involving reflections and denoisers, which we would probably get access soon when 4.24 code starts to appear there with more frequency and so it would be easier to understand if this implementation from @TommyBear is breaking things.
There is still chance for this in my opinion, but one thing is doing PR on a code which is stable, another thing is doing it on a frequently worked code like the rendering module is being for the last months. I got several things I would like to try, but it is really troublesome do something and the chances of it becoming trash because of a change in the engine happen.
Kudos for @TommyBear !
Hi Tommy,
Sorry for your frustration, you deserve a more detailed explanation that what we provided initially. The reason we decided not integrate this pull request is because we have plans to modify that area significantly to make it more performant. Your pull request is indeed correct and adds funcionality that surely users will find welcome. In fact, your implementation is familiar to us: we do pretty much the same in the reference path tracer (pathtracing.ush) for dealing with emissive geometry.
That technique is suitable for interactive rendering but slow for real time, where ray budgets are very low. In fact as you saw yourself you need to increase the amount of samples a lot, cranking it up to 30spp or more to get good results in simple scenes. We have plans to improve our light sampling techniques in the 4.24-4.25 time frame and these improvement will bring this funtionality together with other enhancements. We prefer not to integrate pull request that could collide with the changes we are already working on this particular area. Of course, you all are very welcome to integrate this pull request into your code base in the meantime.
Again, thanks so much for your pull request and sorry for not giving you a more detailed answer before.
Regards,
Juan
