NVIDIA GameWorks Integration

windy has a .18 build with all the bells and whistles inc vxgi and volumetric lighting

who the hell still using Kepler anyway o_O

As I saw in Nvidia sources, VXGI was designed for Maxwell GPUs at the beginning. VXGI 1.0 was extremely expensive. Even the best Maxwell GPU had not enough power to use it in a complete game. So there is no way to use VXGI with old and slow Kepler Cards.

Volumetric Lighting works with minor changes on 4.18 and 4.19. I have it running on 4.19 atm as well but still need to fix few profiler macros, I might push it into my 4.19 GW merged branch eventually. My 4.18 port of Volumetric Lighting is included in (which includes UE 4.18.3, Blast, Flex, Flow, HBAO+3, VGXI1 and Volumetric Lighting).

My 4.19 Gameworks merge ( currently has UE 4.19.1, Blast, Flow, Hairworks 1.4, HBAO+4, TXAA3 and VXGI2 and includes latest fixes from nvidia and one crash fix from me for Flow.

As additional note, I try to keep all my GameWorks commits clearly separate for individual techs if the change is beyond fixing something less important, like UBT warnings. I also prefer keeping each initial merge squashed into single commit. There are few core reasons why I prefer this approach:

  1. it’s easier to upgrade specific individual tech for the next UE4 version as you have all needed things as separate commits with clear indication on what is from original merge and what was changed to make it compatible in case it was ported from earlier engine version. Nvidia usually does it like this as well.

  2. you can cherry-pick individual techs and fixes easily if you don’t want to merge all techs, you only need to have same major engine version (like 4.19.x) and it should be trivial to cherry-pick things without that many conflicts. Had these been in one big commit, it would be way harder for me to separate what was needed to change.

  3. when the original tech branch merge is squashed into single commit, you can easily examine everything that individual tech/commit includes (through github, gitk, or your preferred git client) as it’s not yet mixed with other commits. Of course once there are bugfixes or changes after the merge has been done, those will have to be done in separate commits, so what I said only applies for the initial tech merge for the next major engine version.

There are not as many Maxwell + users as you might think.

I mean it would be nice if VXGI2.0 would also work on Kepler architecture.
We will look at what we can do in this state. Thanks for your advice.
@SilentAndAsleep @alperenozgur

My quick math did tell that on that hw survey, 68,73% of current steam users has Maxwell or Pascal (including first generation Maxwells). But that is irrelevant since even many of those maxwells are not powerful enough to run VXGI properly anyway.


I know that GTX960 and lower graphics cards do not have Maxwell features. Is that wrong?

We need to look at GTX 970, 980, 980ti, 1060, 1070, 1080, 1080ti

Every GPU I listed is based on either Maxwell or Pascal architecture. I don’t know if VXGI feats require second generation Maxwell (in which case for example GTX 750 wouldn’t get fully utilized for this).

But like mentioned already, that’s irrelevant as those gpu’s wouldn’t be fast enough for this purpose anyway.

Thanks for info.

Is anyone else getting this warning in their logs?

[2018.04.30-03.29.40:595][640]LogConsoleManager: Warning: Performance warning: Console object named 'r.HBAO.GBufferNormals' shows many (500) FindConsoleObject() calls (consider caching e.g. using static)
[2018.04.30-03.29.40:595][640]LogConsoleManager: Warning: Performance warning: Console object named 'r.HBAO.VisualizeAO' shows many (500) FindConsoleObject() calls (consider caching e.g. using static)

On another note, this backlogged issue is driving me mad: Unreal Engine Issues and Bug Tracker (UE-33798)

I was just trying an experiment with Blast objects, trying to get 2 to swing into each other. Low and behold, the same issue is present with Blast objects: physics constraint actors and them don’t get along. Anyone know a workaround/trick?

@Gomo I added Volumetric Lighting on…9-GameWorks-VL , I had some issues with it so I didn’t want to put it on the other Gameworks branch. So if anyone wants to try it out, that repo has UE 4.19.1, Blast, Flow, HairWorks 1.4, HBAO+4, TXAA3, Volumetric Lighting and VXGI2.

I have to warn tho that I had some issues on fixing the profiler macros due to the unitybuild issues on volumetric lighting branch. Profiling works now but it’s a workaround and I had to leave some unused stuff as I didn’t have time to spend day or two fixing all the headers properly.

Additionally, I couldn’t get the vl sample to package on shipping conf and while development build packaged, it wouldn’t run on my win10 computer, reporting DX11 feature level 10.0 being required (which my GTX970 does have). Packaged build did run on my win7 and gtx670 computer tho. Also, feature worked just fine on win10 while using Unreal Editor, I mainly had issues on the packaged builds (could be some change I’ve missed). I don’t have time to investigate this further but I wanted to make the repo public in case some people want to try it out. Just be aware there might be issues with it.

Edit-> Apparently the issue I’m seeing on my Win10 machine could be a driver bug with latest Nvidia Drivers (397.31).

As a side note, I do hope Nvidia fixes the non-unity building and properly use IWYU for gameworks tech integrations in the future, there are lots of things missing in the headers that can just randomly break the builds like happened on the volumetric lighting on my end. I’ve previously fixed most of the non-unity build issues on other gameworks techs but VL is probably trickiest of them all, considering it seems to rely on unity build including all kinds of things across it.

More info about IWYU and non-unity builds:…e-what-you-use

@0lento - Thanks for sharing that, and working on it! Hopefully Nvidia cats do indeed work on IWYU/non-unity.

I found a solution to my previous issue with Blast objects and physics constraints: I made the Blast object a child of a dummy mesh, with collisions changed a bit. It’s hacky, but with some tinkering it can work in a pinch.

I just noticed another issue, though. Blast chunks don’t get added to motion blur. I’m hoping there is something simple I’m missing, but I’ve tinkered quite a bit and have yet to find a solution.

@0lento - awesome! I’ll try it today!

I have a question about Hair Works 1.4,Wich is the features of it and why Nvidia have Fur Viewer version 1.2.1 yet?

@Maxime.Dupart is your hairworks okay? i mean. Hairs are not showing in rendered video. But in viewport i can see them allright.

What do you mean by ‘in rendered video’ ?

The branch i’m sharing on github are focused on stability and their ability to package games.
Again, i won’t include TXAA which didn’t improve significantly over Unreal AA in my tests, and i most likely won’t include NV Volumetric light as it hasn’t been officially updated since 4.17 and it took me extra work to have it work and package properly in 4.18 alongside other Gameworks solutions.
Unreal Engine volumetric solution is already amazing for my needs on my current project (there weren’t any volumetric light in Unreal Engine back when Nvidia integrated its volumetric light solution)

legend :slight_smile: will try it out soon as i get home

Fixed the crash, but it still doesn’t work in forward shading mode. VXGI requires deferred shading.

Fixed. Also fixed a similar issue that happened on other types of lights when they have distance field shadows enabled.

Fixed, it doesn’t crash anymore. The latest version will be forced into occlusion-only mode on Kepler.

Verified that VXGI builds without errors in non-unity mode. Posted a note about this request in an internal chat with other UE4 people at NV.

Fixed, now TXAA 3 runs in forward shading mode too.


wow thanks! very noob question. i have to completely re-compile everytime branch is updated right? i just cant download it and re-write files in my already build folder? ( sorry if it sound too stupid but im not very into that programming and compiling stuff, i just love playing with VXGI :stuck_out_tongue: )