RTXGI is great, RTXDI is junk. That's not a real thing

Built the RTX unreal build, GI and DI, loaded a scene and put in just a few hundred lights, got this.

Performance absolutely scaled with light count

What, exactly, is this supposed to do if not this, exactly?

0/10 would not use again, avoid seller, scam.

Hello again,

it is nice to see your interest in NVIDIA RTX technologies. I would kindly like to ask you to maybe spend a bit more time with the subject and the available SDKs, READMEs, Demos and tutorials before giving such a harsh judgement.

There are a lot of games already on the market that are using both these features successfully and with great performance.

The main use of RTXDI is as an external SDK and game specific adjustments, since it has to be tightly integrated with the render-engine of choice. Beside this RTXDI is also still in Beta for the Unreal 5 RTX branch.

In your assessment above I would wish for a bit more information on your setup. Which UE version is this? Is it a release package of the project or debug? Is it the in-editor game render or standalone? What GPU are you using, which NVIDIA driver version, which compiler, etc. This makes it really hard to try and help you identfy why you might be seeing this low performance.

Thank you!

1 Like

Hi Markus,

Sorry I was really frustrated with the seeming lack of ability to communicate with Nvidia of this stuff. Seems like its just a github dump and a ‘you figure it out’. I did actually get this working in the end, so I wanna apologise for that. Its fairly heavy, though, but seems to work pretty well.

Running on a 1080ti with latest drivers.

One thing, if I may be so bold after being such a jerk, my understanding from the demos is that the tech will allow emissive surfaces to actually cast light. You can actually have light bulbs as geometry and do away with point lights in unreal. Is that correct? I haven’t been able to get that to work.

Also its the latest Unreal 4 branch, .7 I think.

Also, a lot of the other ray tech can reduce screen percentage of rays cast. Can RTXDI do this also?

1 Like

Hi again!

No hard feelings, I rather see our technology facing heated emotions and productive discussions than facing indifference (I really need some emoticons here). And you are right, our github offerings can seem daunting and lacking in documentation. That is why we have the Devzone for more learning resources.

All our raytracing solutions are based on the assumption that you are using an RTX generation GPU, which only started with the RTX20 series. So I am surprised you got this working on a 1080ti at all, since that generation only received limted support for RTX. But since they lack the dedicated RTX cores, significantly lower performance is expected.

I am not one of the experts in RTXDI which means I cannot answer your question on emissive surfaces right away, but I will reach out to some people and see if I can get you a reply or a link to some example. The documentation does state that you can create mesh and triangle based lights, so i think the answer is yes, but I could not find an example so far either.

Also, a lot of the other ray tech can reduce screen percentage of rays cast. Can RTXDI do this also?

Do you mean some visibility/occlusion checks or light culling? Part of that is implicit in the algorithm, but depending on the integration you will retain any functionality in visibility handling based on your original render engine. I am not aware that you can limit the screen space area where ray tracing is applied, which would not make much sense in any case.

Can you point me to some example of “the other ray tech” you refer to here?


Thanks for the reply, and that would all be much appreciated!

Im not 100% sure how the DI algorithm actually works so I might be talking nonsense, but ray reflections for instance can be reeled in a little bit with something like r.raytracing.reflection.screenpercentage=[number] console command. (That might not be 100% word for word correct I dont have it opened right now)

This significantly improves performance without a particularly noticeable visual downgrade that with the help of art style is quite acceptable for the 1080ti. You cant go below 50% however without a very strange jumping or jittering visual bug

The same trick can be used with shadows.

I was wondering if there is a similar optimisation to be found with RTXDI

Regardless, yes please do let me know about geometry/texture emission because as you say the documentation mentions it and so do your demos, very proud of millions of emissive polys, so I assume unreal must also be able to do this. It might be some difference in rendering or whatnot, though.

Hey any update on this?

Hi captain_keys_343,

in fact there s, yes. For one thing it seems that emissive triangles are not yet supported on UE4. The people I asked are very certain it has been listed as a “possible future feature”, but it might not have been completely clear in all our supplied demos or tutorials.

Beside that one of the engineers will join the discussion on this soon, depending a bit on work priorities.


1 Like

Please thank them for their time for me!

1 Like

Will do.

Thank you!

Hi captain_keys_343,

I’m the maintainer for the RTXDI support in our UE branches. Markus tracked me down to try to help you out.

First, on the emissive surfaces, that is a general feature of RTXDI, as you mentioned. However, the implementation in the SDK has a few requirements that UE doesn’t meet. This forces us to use a different approach, and it has been in the backlog for a while. Unfortunately, it has been behind other priorities. The way UE materials drive emission is the key complicating factor here. Additionally, we know that using emissive surfaces as primary lights is a non-trivial impact on the art pipeline, so we tend to prioritize things someone can just turn on higher. We try to be clear about the fact that emissive surfaces are not yet supported in communications around RTXDI support in UE.

Now, on the performance side, I think I might need to see your project to understand better. There are a few things that could be the issue here:

  1. It is easy to get software bound in UE with lots of moving lights. If you’re software bound, obviously, GPU optimizations can’t help much. Some of this work can possibly be skipped when RTXDI is active, and I’ve recently taken a look to see what we might be able to do.
  2. RTXDI has a certain fixed overhead. If your lighting is under that threshold cost, you won’t see scaling. This is much worse with pure point lights (no area), as these already require no denoising in UE. Today, that breakeven can be around 20 lights, based on internal testing. Importantly, this is heavily dependent on item #3 below.
  3. RTXDI has a lot of settings. The defaults are definitely toward the “Epic” settings level. One of our technical artists has recently done work to better calibrate things for out of the box experience. We’ve got an update rolling in our next official release. This work includes proper scalability levels that should help you choose a better level of settings for your project.

The last item is both a challenge and a strength of RTXDI. Traditionally, you have pretty limited ability to scale shadowed light costs. RTXDI allows for a much more continuous tradeoff of quality versus performance. However, picking the right balance of settings becomes more complex.

On the scalability question of reduced resolution, RTXDI doesn’t really work well with straight screen percentage techniques like reflections or AO. You’ll notice that the ray tracing shadows in Unreal also lack this, because it just doesn’t work that well. The baseline RTXDI SDK offers checkerboard scaling, and we intend to enable this in UE as well. We’ve just been focused on other issues, but it is something I’d like to complete soon. There are some complications in the way UE dithers and checkerboards other effects that complicates this. We’ve encountered a few other case where temporal effects can interact in a “beat” pattern that causes flashing, so there is some additional validation effort required here.

Anyway, thanks for reaching out. We really want to improve this feature as we feel it offers a lot to those that want to scale up to more complex lighting environments, and I’d happily take more of your concerns.



Thanks for your time, Evan!

Okay so for #2 you mentioned that point lights should be pure point lights for best performance? With no source radius?

Otherwise, yeah I was wondering because Unreals emissive shader is a bit different if all that would be the case.

Its interesting that you feel that using emissive textures would be harder on artists in terms of scene lighting. I would find the absolute opposite. But I understand its not exactly like just tapping a checkbox haha.

More settings for RTXDI would be very welcomed. The overhead is totally worth the trade, even so, as you say. I was just hoping there might be a quick hidden little switch that might have got a few extra ms, its really overoptimising at this point, but its good to know this stuff ahead of time so if I need it later I have that knowledge in the toolbelt.

I really appreciate your time!

To be clear, pure point lights are more efficient without RTXDI. With RTXDI, they are little if any faster. So, if you’re comparing point lights in normal UE vs RTXDI, you’ll see less advantage to RTXDI. Where you’d possibly skip the area to save cost in normal UE, RTXDI will allow you to set a source radius for virtually zero cost.

The art challenge is a subtle one. If you are authoring straight for RTXDI, it is not really a challenge. However, if you’re authoring to run across a lot of HW, you typically will have proxy lights surrounded by emissive meshes. For this case, RTXDI with mesh lighting will end up doubling your lighting, if it samples both the mesh and the proxy. My goal has been to allow people to load scenes that they already have, and have them ‘just work’ even if not faster. For instance, you can turn on RTXDI in the old Infiltrator scene, and it’ll run with something like 700-1500 shadowing lights with RTXDI enabled.

FWIW, I don’t think we’ve added any “new” settings for RTXDI other than the scalability options. Those actually drive the existing options. (r.RayTracing.SampledLighting.XXX)

The top ones for getting some quick perf (with possibly lower fidelity) are:

r.RayTracing.SampledLighting.Spatial.Samples (min 1, max 32)
r.RayTracing.SampledLighting.Spatial.SamplesBoost (min 1, max 32)
r.RayTracing.SampledLighting.Spatial.ApplyApproxVisibility (0/1, will make shadows less crisp)
r.RayTracing.SampledLighting.Temporal.ApplyApproxVisibility (0/1, will make shadows less crisp)

Keep in mind they will only help if you aren’t software bound.


1 Like

Uhm, Evan.

Okay so i’ve got an RTXGI volume attached to a player, set to infinite scroll, works great… unless I change verticality

Any stairs cause probes to momentarily, like even just a few frames, decide they should sleep, which seems to purge them of lighting information, and they then have to rebuild it.

Basically, all staircases flicker black awfully for no reason.

Is there a fix for this or a way to disable this behavior?


I’m sorry, I’m an expert on RTXDI, and while I understand the generalities of RTXGI, I’m not an expert. I’m passing your question to our experts on the UE RTXGI plugin.

Hi @captain_keys_343,

I’m the lead for RTXGI. Evan pointed me to your question, so I’ll try to help.

First, I’m sorry you are having troubles with RTXGI in UE. At the moment, the RTXGI UE4 plugin has some issues, one of which you’ve run into. If you are using the binary plugin (from the marketplace) it is not possible to disable probe classification - the feature that decides when probes should sleep or be active. Something to try: disable probe relocation (this is an option on the DDGIVolume in the binary plugin). Relocation may be causing probes to reposition in a way that triggers classification to do undesired things.

If that doesn’t help, you can switch to the source code version of the plugin and disable classification by changing the code. I know this isn’t an ideal solution (particularly if you are not a programmer) and we’ll be working to improve the plugin’s options in the future.

Hope that helps,

P.S. Nice Halo: CE reference in your user name!

1 Like

Thanks, thats awesome you noticed. I’ve had this email since 2001. My only annoyance is that its actually Captain Keyes, with the extra e. Sad haha.

I’m using the RTX build github branch. Probe relocation wasn’t it, good suggestion though. I even tried moving the volume in blueprints only once a second, rather than having it attached to anything. It just hates moving vertically I guess.

This tech is really fantastic generally, you and your team are doing really, really impressive stuff. So thanks for all that hard work, im blown away by the promise of all this.

That said haha,. yeah thats definitely… suboptimal. I guess its pretty state of the art but these issues are pretty significant.

The ability to disable that behavior, or get the probes more temporally stable with their shutdown would be really useful. Pretty rough to get a usecase out of this at this stage, I have to say :(

1 Like

Okay, two more thoughts:

  1. Since you are using our GitHub branch of the engine, there is a small code change you can make in the plugin that will disable classification for all volumes. This might not be the best general solution (e.g. if you want classification with other volumes in the scene), but if you are using a single ISV on the player this could solve your problem if you are feeling adventurous. Change this line.


static const bool c_RTXGI_DDGI_PROBE_CLASSIFICATION = true;


static const bool c_RTXGI_DDGI_PROBE_CLASSIFICATION = false;

and then compile the engine. Probe classification will be disabled.

  1. There is another option that doesn’t require any code changes. Surfaces in the scene receive indirect light from a single volume, even when there are multiple volumes in the scene. We can take advantage of this.

Place another DDGIVolume in the scene that covers the problem area (stairs). Volumes are sorted by lighting priority, then probe density, and the volume with the lowest priority value and/or highest probe density is chosen. So, either set the new volume’s lighting priority to a lower value than the lighting priority value of the player’s ISV or give the placed volume a higher density of probes than the player’s ISV.

With this setup, the stairs will not receive indirect light from the player’s ISV, so the classification problems will not cause visual issues.

Not ideal, I know. But, a workaround for now.

Yeah im using multiple volumes as gi lods basically, haha, so I can try flip the bool if that doesnt totally break multiple volumes, you seem to be saying it will.

The 2nd option is a good one, but the world is dynamic and generated from tiles or other instructions, so I cant precalculate anything. ugh, such pain hahah.

Its awesome you came back with that stuff, really, thank you for trying!

Okay, since your world’s geometry isn’t static or predictable that does make it tougher to use the second solution. Swapping the bool won’t break multiple volumes, it will just disable classification globally. This means all probes (in all volumes) will trace rays, which will be more costly. Disabling classification on the ISVs should do the trick for your use case though, with the tradeoff of a higher performance cost for visual consistency.

Hope that gets you unblocked!