Download

NVIDIA GameWorks Integration

@Maxime.Dupart
I don’t have hard numbers, but I can say that from my tests (I’m actually compiling your fork right now) with diffuse tracing and ambient occlusion, the new AO doesn’t appear to be incurring any hits to performance. The visual addition is well worth the sub-millisecond hit, if any, in my opinion. Area lights definitely hit my sad rig hard (rocking a GeForce 750ti), I usually lose ~10-20 FPS.

I’m starting to zero in on magic numbers to get good performance and quality balances, with a main directional light, sky light, and several area lights in a test scene. Fullscreen at 1920x1080, I was getting about 20-30 FPS with higher quality settings. I can imagine that newer GPUs would be getting healthy 60 FPS rates. I plan to cook out a test and pass it on to some peeps to verify that for rigs with better specs, ranging from GeForce 960s to 1070s and I think an AMD GPU somewhere in that pool. Here is a shot from that test scene:

Would be awesome, i would gladly give feedback on your test scenes if you’re interested (currently using a GTX 1080 at 4K). Area Light being completely isolated, it does create its own overhead. If i were to consider using Area light + core VXGI, it would mostly be for the voxel-based AO.

Just did the test on my side with outdoor landscape scene and indeed activating VXGI on lights/skylight, even if there’s no PostProcess with VXGI On in the scene, creates a really noticeable overhead.

That makes sense that one can’t use a material, yeah - an animated texture like scene capture 2d or media texture would be amazing tho! Especially media texture!

Would it be helpful if I submit this as an issue for you in GitHub? :slight_smile:

I have no plan to include nor Nvidia Volumetric light nor TXAA for now. I do love Unreal engine volumetric lightning (which wasn’t available back wen Nvidia solution was), and i didn’t feel like TXAA was a massive improvement over Unreal TAA: to be honest i haven’t noticed any difference, maybe i haven’t looked into it hard enough.

After much tinkering, I’m really liking the screen space shadows that area lights produce. I’m having a heck of a time getting them stable though. Another thing I’m doing is a quality-of-life BP based on the area light actor, that has all those settings, but also drives some material parameters and a few other goodies. In doing that, I realized I should make a sort of core controller BP and tie that into a UI with sliders and buttons and checkboxes, for quicker experimentation with all the settings we have available. Once I get that all tied together, I’ll drop the demo scene in this thread for peeps to experiment with. Could be a bit though.

I’m really excited to start seeing some concrete numbers and stats. Lighting has always been a mysterious creature for a lot of people, and being on the cusp of a solid GI solution is awesome. I’ve tried quite a few different solutions, and by far VXGI has been the most approachable and applicable in different lighting scenarios. Save for large outdoor/landscape scenes. Granted, I bet with some tweaking, we can figure that out too.

We’ll be able to figure this out once Unreal starts having good performance for large outdoors without any GI enabled. This is really Unreal’s biggest weakness. In CE/LY you can fill a big map with lush foliage and dynamic GI, it will perform a LOT better than Unreal with smaller scenes. I really hope they will adress this issue soon enough.

I’m consulting on another team’s project, and took on the task of pulling in a LIDAR scan of Crate Lake, Oregon and running that through World Machine, then pulling into Unreal Engine. It’s a 1:1 scale of an 18km^2 area. It has a lot of trees, rocks, and grass/foliage. A *very *complex material (shows up nasty red in the shader complexity view)… I pull a steady 60 FPS on my potato rig. It really comes down to knowing how to work with the tools ya got. CryEngine has always been tailored to large outdoor terrain, since the first Far Cry. So of course it’s going to shine there. CryTek certainly does a good job of coming out with new tech, no doubt about that. Alas, UE is capable of just as fancy large outdoor areas if you know what you’re doing :wink:

LogD3D11RHI: Error: VXGI Error: VXGI requires a GPU that supports FP16 typed UAV loads natively (DX11.3) or through NVAPI (Maxwell+) when ambientOcclusionMode = false (GI_Base.cpp, 366)

@Alexey.Panteleev >> @Maxime.Dupart
What does that mean now? Will it only work in Maxwell+ after that?

It is nice but it should be a continuation.

SHA-1: 375d35e3e1574030cbf99bc6c6c39082c0b027b9

  • Fixed the crash that happened on the creation of shaders when the GPU does not support FastGS.
    If the GPU doesn’t support typed UAV loads on FP16 data, it will still crash unless r.VXGI.AmbientOcclusionMode is set to 1 before enabling VXGI.

I was actually the one that pointed out that issue. The latest version works for me, and I can freely change r.VXGI.AmbientOcclusionMode, now that shaders have compiled and such. My old boat is still rocking a GeForce 750ti.

@Maxime.Dupart my friend just did same test on 4.19.1 Official Nvidia Branch. He says there wasn’t an fps drop until activating VXGI in Post Procces Volume. Are we have this situation because of 4.19.2 or is there a complication with gameworks features or something like that?

Unless I’m missing something with your issue, you can of course expect a performance drop when enabling VXGI. It’s not free, and the more features/combination of features you enable, the bigger the performance costs. I’m guessing I’m missing something specific though, lol

Of course, VXGI is an expensive feature but the problem is not its cost. I have already shared an ss. I will upload it again with some additionals to make it easy to understand. As you can see in the middle (which is vxgi enabled only on directional light but not in post process so there is no any visual change), there is a 30 fps drop but vxgi not enabled yet and there is no any vxgi element on GPU profiler. And according to my friend, this is not happening on 4.19.1 Nvidia branch. Also, another interesting situation is somehow GPU profiler can’t capture or cant see some elements because in all scenarios GPU profiler shows lower frame times than viewport values.

woow. im about to get excited. But what’s new? :smiley:

New bugs :slight_smile:

I found the cause for this perf drop. When a directional light has VXGI enabled, its shadow map is set up differently, with more objects being drawn into the shadow map to avoid indirect light popping when you look around. The problem is, that code doesn’t account for the other VXGI settings being used, i.e. it shouldn’t do that in VXAO/AL mode or when it’s not enabled at all. I’ll fix it next week.

What’s New in Version 2.0

  • VXAL, or Voxel Area Lighting
  • Improved overall performance
  • One-pass voxelization
  • Simpler controls for tracing and voxelization
  • Support for custom G-buffer layouts
  • Stereo view reprojection
  • Simultaneous VXGI and VXAO

Well, VXGI 2.0 actually requires a GPU with certain post-DX11.0 features to be completely functional. There is no plan to make it compatible with older GPUs again. But you can still use VXAO/AL on Kepler, for example.
It shouldn’t crash though, I admit. That is to be improved.

@Alexey.Pateleev

Thank you for your devoted work. Is it possible to use VXGI 1.0 on UE4.19? I think it was a very sudden end to VXGI 1.0.

Thanks Alexey for your efforts on keeping VXGI alive! In my limited testing it’s a major improvement. A few issues so far with the NVIDIA 4.19.1 build…

I’m assuming it isn’t compatible with Forward Shading? Every time I try to open a level with Forward Shading enabled it crashes the editor.

I can get it working in VR (using Deferred Shading) but performance on a simple scene is still less than optimal. Any VR settings recommendations would be great to hear about.

On that note, have you thought about putting together 1-3 sample scenes representing simple yet optimal setups? It might alleviate many of the questions about best practices.

LOL why would you use an inferior version