NVIDIA GameWorks Integration

[ThaLobsta]

I've been trying to debug what may be the same problem. Specular works fine in the editor, but in the game it takes a lot more time to produce an incorrect result. Diffuse works fine in both. If I change the ReflectionApply shader to just output the VXGI specular buffer, this is what it outputs in game vs editor:

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.

Yes I noticed that too. SSR gets disabled somewhere else earlier AFAICS. I dont know where.

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.

// NVCHANGE_BEGIN: Add VXGI
#if APPLY_VXGI
	SpecularLighting.rgb = ScreenSpaceData.VxgiSpecular.rgb;
#endif
// NVCHANGE_END: Add VXGI

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

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.

[Number47]

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.

Thanks! I can repro the stuttering now and will look into it.

[Mike.Skolones]

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.
--Mike

[Chesire]

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.

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.

[Semaphore]

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

[Darth_Ciltress]

Hello Mike,

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

[trungswat]

Yeah it definately looks like tessellation is broken, I don't test very often with it on, so didn't notice until now. I dont think VXGI is to blame, Its going to take me a bit to figure out where the fault is.

EDIT: Okay fixed, as i had suspected, it was the FleX fluid vertex factory causing the issue, put in a clause to only cache if tessellation is not enabled. So I wouldn't try creating a flex fluid shader with tessellation turned on, will probably crash. Not that tessellation is support on the flex fluid surface

Hi,


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?

[GalaxyMan2015]

Hi,


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;

[Mike.Skolones]

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

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.

--Mike

[trungswat]

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;

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

[BrickTop]

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.

Thanks!

[enoes]

nothing package project this version please fix this

[Chesire]

I was wondering if shader compiling with vxgi still taking few minutes to complete, like before?

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!

[Johny]

Hello

I have a small question, would it be possible to specify the engine version in the readme.md of the branches of NvPhysX fork without the need of downloading and compiling each branch? What i mean for example the new turbulence branch has 4.7.6 in it's name. Unfortunetly the tags are lacking behing quite a bit (4.6.0) and names of the branches does not specify versions. Like for example there in flex branch in readme.md just change the "NVIDIA Flex - UE4 Branch" to something like "NVIDIA Flex - UE4 Branch 4.8.1.1" where 4.8.1 is the engine version and last .1 is flex implementation version. or something like that.

Of course you dont need to specify the additional .1 in the about of the engine itself. I just mean the readme.md in the git so that it would be able easy for people to tell what version is it or if it was updated.

[BrickTop]

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!

Thanks, Chesire! I will give the latest one a try.