NVIDIA GameWorks Integration

I’m having issues with the branches with VXGI 2.0. Whenever I turn on VXGI Diffuse everything in the scene turns red. I’m uploading two screenshots with VXGI on and off for comparison. Also, when i turn on VXGI Specular I get the following error:

[File:C:\UnrealEngine-4.19\Engine\Source\Runtime\Windows\D3D11RH\Private\D3D11NvRHI.cpp] [Line: 257]
VXGI Error: computeSpecularChannel is unsupported in Ambient Occlusion mode [GI_ViewTracer_Specular.cpp, 48]

I already installed this branch in another PC with no problems, so I have no clue about what went wrong here. The PC I’m trying to run this branch on has a 780GTX Ti and Windows 10, while the other PC, with the working engine, has a 970GTX and Windows 7. Those are the only differences.

Any clue about how i could fix this? Thanks in advance!

It won’t work on a 780 because it’s Kepler. You need at least 750 Ti (Maxwell-1) or 9xx to run VXGI in non-AO mode. Also, are you running the latest version that I pushed yesterday, or something older?

@0lento - your branch seams to work fine. I had some issues but they turn out to be my bugs.
So for tried on three projects - no crashes so far.

I updated all three 4.19 GameWorks merges I’ve done to include latest fixes from Nvidia (for TXAA3 and VXGI2) and official UE 4.19.2:…4.19-Flow-VXGI (Flow + VXGI 2)…4.19-GameWorks (Blast + Flow + HairWorks 1.4 + HBAO+ 4 + TXAA 3 + VXGI 2)…9-GameWorks-VL (Blast + Flow + HairWorks 1.4 + HBAO+ 4 + TXAA 3 + Volumetric Lighting + VXGI 2)

That’s nice to hear, but do test the packaging too. Like mentioned I couldn’t use shipping conf on Volumetric Lighting for some reason on my initial merge. There could be some issues with other techs on shipping builds too as I haven’t tested that conf extensively.

Development conf on each GameWorks tech seemed to package just fine (I’ve test packaged and ran the packaged version for at least one sample from each GameWorks tech to make sure everything seems to be in order on packaged builds as well).

Please, can somebody test trueSKY with VXGI 2?

I’m using Truesky with VXGI 2.0 since VXGI 2.0 came out and have no issue ^^

Then I keep trying. VS2015 may be having problems. Thanks for the info.

thanks for the quick reply. I just tried your latest build and the issues are gone, no more red light and no more crashes. Is there anyway I can use VXGI in this build with my 780, since r.VXGI.AmbientOcclusionMode= 0 means no VXGI and my GPU doesn’t support r.VXGI.AmbientOcclusionMode= 1?

r.VXGI.AmbientOcclusionMode= 1 means you can only use VXAmbientOcclusion.
r.VXGI.AmbientOcclusionMode= 0 means you can use Full VXGI+AmbientOcclusion.

@Alexey.Panteleev I have just tested the updated branch. I noticed VXGI voxelization and tracing frame times are good but when I enabled VXGI (Only Directional Light) with optimized parameters, my fps drops 97 to 48 on GTX 980Ti because of shadow depths. Is It usual or there is another problem? I uploaded GPU profiler results. First: Shadows and VXGI enabled (GI only). Second: Shadows enabled but not XVGI. Third: Shadows and VXGI disabled. Fourth: Shadows disabled VXGI enabled (GI only). Also, I noticed that in fourth scenario GPU visualizer shows 3 ms less than viewport values. Is this “half of the fps” situation nature of VXGI? I thought that VXGI 2.0 would be much faster than old one, up to 2x according to updates. But fps which I had drop doesn’t verify this is true.

@0lento - I’ve managed to package project using your branch.

In this case, a large part of the fps drop comes from shadow map rendering, the ShadowDepths pass. Like I mentioned, when VXGI is enabled, the directional light shadows include all objects that are covered by the shadow map, not just those affecting the current camera view. You can see that using “vis ShadowDepthAtlas” or “vis WholeSceneShadowmap” and toggling VXGI on and off. It’s probably possible to do some culling still, or limit the range of cascades that are used for VXGI. Since you observe such a significant slowdown, it would be great if you could send me the scene, or something else that reproduces the same kind of slowdown, and then I can try to optimize the code (or settings).

VXGI 2.0 is generally faster than 1.0, but no one said you will see 2x speedup overall. In the GDC presentation, I mentioned that voxelization can be almost twice as fast in some cases, mostly because it can be done in a single pass now. Other things like voxel processing and tracing have been somewhat improved. But not shadow map rendering, as that’s part of the engine, not VXGI. (Actually, it’s probably possible to implement single-pass directional shadow map rendering using Maxwell-2 FastGS, which should give a speedup for everyone using UE).

Hey, I’m kinda curious since you specify ‘HBAO+ / HBAO+ 4’ for some of the builds.
It’s a bit confusing since there’s already a feature in the VXGI builds that’s called hbao.

I’m assuming what’s in the VXGI builds is actually the Voxel AO / VXAO.
While when you specify HBAO+, it’s the screen-space HBAO from a separate branch?
( aka the one from here NVIDIA ShadowWorks | NVIDIA Developer , but without shadowworks itself, which doesn’t seem to have any kind of UE4 implementation yet. )

VXAO and HBAO+ are in fact two different bits. HBAO+ also is in VXGI builds by default, just not sure if it’s HBAO+4. Maxime, 0lento or Alexey would know better on the differences there. And ShadowWorks is something totally different from the ambient occlusion stuff.

What would that process look like? Is that something simple to do?

Hi Alexey,

Not sure if this is easily fixed but making a typo when entering a voxelsize in the console (example ~32 as opposed to 32) will crash the editor.

It’s HBAO+ from VXGI2 branch. I specify it separately as it’s a separate GameWorks tech from Nvidia, it’s not coupled with VXGI technically in any way, they just chose to distribute them at same merged branch.

Meaning, you can technically strip out all VXGI code from the nvidia VXGI branch and have only HBAO+ left and it still works (we’ve done that for UE4.15 when I didn’t need VXGI for anything).

thank you for this important information. If there is a way to have a more optimized VXGI I will do whatever I can. If you send me an email or something like that I can send a scene to reproduce. And also dynamic shadow cost is a big deal in Unreal for open world. If its performance will be improved too, with VXGI, Unreal would be a better position for open world to compare with CryEngine.

Hey, what’s up UE4 community. I’ve returned to Unreal Engine after being away for 2 years. I was one of the early developers who kept begging Epic to implement a dynamic GI solution after SVOGI got canned. Things looked grim for me until I came across VXGI and started following it. Now after seeing the cool new results being achieved with 2.0, now feels like the time to return back to UE4!


Hey dude, I want to thank you for your work on VXGI. It reinvigorated my interest in real time rendering again and it’s cool to see you’re on the forums. I was wondering, with the latest Ray tracing announcements from Nvidia and Microsoft, what will the future of VXGI look like? Will it continue to be its own thing or will it eventually merge with those new technologies?

Yes, HBAO+ 4 is integrated in the VXGI branch.
ShadowWorks is a marketing name for the collection of HBAO+, PCSS and HFTS: NVIDIA ShadowWorks | NVIDIA Developer
UE4 has a PCSS feature of its own, but HFTS is not integrated, as far as I know.

Implementing single-pass cascaded shadow maps is not exactly simple. Overall, it would replace the regular CSM rendering passes with one coarsest cascade, and use multiple viewports to represent all the cascades at once. The new pass will use a FastGS shader to multicast each triangle into a number of those viewports, depending on which cascades it intersects with. There may be complications though: if shadow maps are too large, the DX limit on viewport size (+/- 16k pixels) can become a limiter, in which case it will be two passes instead of one. There also may be some accuracy issues.

We have a sample that does this (in GL):

This was fixed yesterday. I added some validation/clamping on the important cvars. Turns out ~32 translates to just 0.

​​​​​​​You’re welcome! :slight_smile:
Yes, VXGI is playing in the same field as the ray tracing tech, sort of. And it doesn’t give the same level of image quality. But VXGI is much faster than ray tracing, if you implement similar effects using both. There are some possible paths for them to converge, like using RT for mirror reflections and VXGI for everything else, or using RT for contact shadows. We’ll look into that.