NVIDIA GameWorks Integration

[Gandosh]

@Mikand79;316312

My card is too bad to handle VXGI spec anyways but always know all your options. VXGI specular is quite unsharp isnt it? Looks gorcious for soft polished things but if you need something sharper…

Dynamic reflection captures would be cool. (probably exist but Im too numb to know how to enable and use them)

yeah but it does the job By the way i hate SSR with its pixelated result. Only thing that i love from SSR is floor, flat surface reflection

[Netrve]

@Mikand79;316312

Dynamic reflection captures would be cool. (probably exist but Im too numb to know how to enable and use them)

You’re not alone, I also wonder if there is a way to get dynamic reflection captures, but haven’t found anything on the forums yet.
I’m not sure if it would work by just exposing the update functionality to make it blueprint callable, but might be worth a try? (I’m not a coder, so is just a guess)

[anonymous_user_446c5d2e]

@.;312681

All of these branches are PC-only.

Hey guys, I’m running Ubuntu 14.04 and having trouble getting 's merged version to compile. I’m mostly interested in the Flex integration, and Waveworks when it is available. Machine is dual Xeon E5-2640 with 4 Titan Blacks, CUDA 7, with NVidia driver 352.21.

On the Flex side, the supplied binary demo runs fine. Recompiling on the machine, however, seems to negate all of the collisions and all but convex meshes and sdf fall through the domain and pass through each other.

Is anyone else performing builds on a linux box with success?

[SaviorNT]

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

[Mike.Skolones]

@Whoop86;316467

Hey guys, I’m running Ubuntu 14.04 and having trouble getting 's merged version to compile. I’m mostly interested in the Flex integration, and Waveworks when it is available. Machine is dual Xeon E5-2640 with 4 Titan Blacks, CUDA 7, with NVidia driver 352.21.

On the Flex side, the supplied binary demo runs fine. Recompiling on the machine, however, seems to negate all of the collisions and all but convex meshes and sdf fall through the domain and pass through each other.

Is anyone else performing builds on a linux box with success?

Currently all the GameWorks branches are Windows-only.

[Chesire]

@ > 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?

[anonymous_user_bcf66e2c]

@;316739

@anonymous_user_bcf66e2c > 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.

[WuRuiHeng]

@

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 )

[anonymous_user_bcf66e2c]

@WuRuiHeng;316786

@anonymous_user_bcf66e2c

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

[WuRuiHeng]

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

[ThaLobsta]

@AndrewJSch;315424

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, is what it outputs in game vs editor:

FWIW I randomly had 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.

@Mikand79;316282

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. 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 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 looks like a bounds. The FlexFluidSurface component gets the bounds from the connected emitter instances. I haven’t been able to reproduce the. 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.Schirm;309781

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

[Mike.Skolones]

@;317125

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

Indeed looks like a bounds. The FlexFluidSurface component gets the bounds from the connected emitter instances. I haven’t been able to reproduce the. 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 week, but I’m working to integrate and push the changes he left for me onto the NvPhysX branch.

[Chesire]

@;316749

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 of course works fine. I’m clueless as to what gives.

[Semaphore]

Hello ,

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 ,

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

[trungswat]

@;299143

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, 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 due to Flex fluid vertex. Could you please clarify more?

[anonymous_user_bcf66e2c]

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 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]

@Semaphore;317327

Hello ,

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.

–

[trungswat]

@;317688

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.