NVIDIA GameWorks Integration

Figured I would chime in with a +1 for Epic to implement plugin support for modifying the rendering engine. I have serious doubts about my skills as a github user and getting everything to play nicely. This would also be a huge benefit for the ArcViz crowd that may or may not be programmers. Going from AutoCAD / Inventor to UE4, and then needing to learn about github branch management and compiling? No thanks!

Please Epic!

Currently all the GameWorks branches are Windows-only.

@Galaxyman2015 > Could it be your build messes a bit with the new 4.8 procedural foliage volumes? They seem to be missing their boundingboxes as well as the simulate functionality. ‘Flex’ collision?

No, hadn’t actually tried them, so I gave them a go now and everything seems to be in order. I can see the bounding volumes, and the simulate seems to work fine.


thank you for your help we finally can play with the magic of nvidia.:o

and … is it somethings special need to known if I want to package my level(try a lot of times and even copy to other’s PCs,it still not succeed )

I dont believe packaging works at this time for my build, I know there are a couple of pull requests on the main NVIDIA branch for fixing packaging with HairWorks, so maybe imlpementing that would allow packaging for all techs to work (maybe not). Each tech might have its own reasons for packaging failing. At this time I have no plans to look at that, as my version of the engine is still in constant flux, once it settles down and I have all the features I want, then I will take some time to look at it, but that is still a while away.

I am happy to accept any pull requests from anyone who may be looking at fixing packaging.

thank you !!!You look like you’re always online!!! thank you so much!!!:o

FWIW I randomly had this happen in an editor session as well, and I figured out it was caused by the specular filtering by playing with the post process settings. Can’t explain why it wasn’t happening in the 4.7 build, or why it only seemed to be happening to me, but disabling specular filtering in the post process settings avoids the problem for me. It’s on by default, which seems unnecessary when specular jittering is off by default.

You’re looking for DoScreenSpaceReflections in ScreenSpaceReflections.cpp. If VXGI specular is enabled, then it just returns false. IMO it would be better if you could enable both without changing the source code, but the VXGI branch defaults should probably change SSR to default to disabled.

If you enable VXGI+SSR, you probably also want to change ReflectionEnvironmentShaders.usf so it blends SSR with the VXGI specular.

	SpecularLighting.rgb = ScreenSpaceData.VxgiSpecular.rgb;

	float4 SSR = Texture2DSample( ScreenSpaceReflectionsTexture, ScreenSpaceReflectionsSampler, UV );
	SpecularLighting.rgb = SpecularLighting.rgb * (1 - SSR.a) + SSR.rgb;

You probably also want to lower the max roughness that SSR will be done for so it only uses it for smooth surfaces. For me, SSR+VXGI fixes more artifacts than it adds:


It’s probably possible to fix SSR artifacts like the false reflection underneath the sphere by making it more conservative about what it considers a hit, since VXGI can fill in for situations where SSR doesn’t have enough information.

Hi Simon, are there any news with Flex and the stuttering and adding surface emitters to blueprints issues?

Indeed this looks like a bounds issue. The FlexFluidSurface component gets the bounds from the connected emitter instances. I haven’t been able to reproduce the issue. If you haven’t already, could you try to turn off the surface rendering, and re-enable the particle rendering to see whether it happens in the exact same setup otherwise?
I believe that the problem lies with the flex fluid surface since rendering flex particles (balls) works fine. I have noticed that when I was testing the fluid surface I was at +35286 on Z-axis in my level, and when I moved the flex fluid surface emitter to 0 on Z-axis there where no stuttering at all.

Simon is out this week, but I’m working to integrate and push the changes he left for me onto the NvPhysX branch.

Weird. I downloaded your branch again and recompiled just to make sure but no dice. When I create a procedural foliage volume it says it’s a flex actor. The entire procedural foliage tab is missing so no simulate button either.
On the Epic 4.8 branch this of course works fine. I’m clueless as to what gives.

Hello Mike,

When can we expect a merged branch with all nVidia tech released so far that is compatible with 4.8?

Keep up the good work :slight_smile:

Hello Mike,

is there a release date for the Maya 2016 Hairworks plugin?


I’m using OceanShader with UE4.8 integrate with Nividia GameWork. I’m stuck in the same problem with ‘FVertexFactoryInterpolantsVSToDS’ error in material editor.
I’m not clear how to fix the issue due to Flex fluid vertex. Could you please clarify more?

It seems the change didnt make it through to my 4.8 branch, but in the function ShouldCache of the FFlexFluidSurfaceVertexFactory in Engine/Source/Runtime/Engine/Private/PhysicsEngine/FlexFluidSurfaceComponent.cpp you need to change “return true;” to

return Material->GetTessellationMode() == EMaterialTessellationMode::MTM_NoTessellation;

We’re working on the individual branches right now, I’m looking at the FleX upgrade today (with more changes on the FleX side, including support for a new kind of soft-bodies); the VXGI team has the upgrade done and we’re planning to push it by next week. The other branches should follow reasonably quickly. Regarding an all-in-one-branch, I don’t have an official ETA.


Thank dude, work like a charm. You’re so genius.

Hi guys,

I was wondering if shader compiling with vxgi still taking few minutes to complete, like before? I would like to try to use this tech in production, but shader compilation times seem to be a major drag as of now. Also, if that’s still the case, will it be addressed in the future?

Another question is - how soon do you think it will take for HBAO+ to make to the official branch (in 4.9 maybe?), as per my tests it works perfectly in its current state.


nothing package project this version please fix this

Compilation times have been significantly decreased in latest build.
Things still depend on the amount of shaders and individual shader complexity but overall it’s much more workable!