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.
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?
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.
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.
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:
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.
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.
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.
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.
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.InitialSamples
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.
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.
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.
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 :(
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.
and then compile the engine. Probe classification will be disabled.
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.
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.