NVIDIA GameWorks Integration

Hi guys,

So the big plan is to Wavework and try to get Truesky to work with it. But first baby steps :wink:
I think Iā€™ve got Waveworks in my ue4 (atleast i built accordingly) but i donā€™s see the example map.

What is the way to make the waveworks ocean? Canā€™t seem to find itā€¦ I can find the shoreline capture howeverā€¦
Thx for the help!

4.18 btw

edit: silly meā€¦ found the example map

Hey guys,

Iā€™ve been waiting a while for Nvidia to update all their branches to 4.20 (Iā€™m specifically waiting on VXGI but official updates on the others would be nice as well) and Iā€™m getting a bit concerned.

/releases

Going back 2+ years thereā€™s at least 1 release from nvidia every month, most the time 3 or 4 even during other major UE4 version updates, but now we havenā€™t heard from them in almost 3 months.

I canā€™t find any posts on the Nvidia dev forums or Reddit regarding and the support page on the GameWorks/UE4 website just links to thread.
Am I missing something? Is it possible they are planning on dropping direct support for GameWorks on UE4?

(Also thanks to and others on their amazing work on upgrading some of the branches manually and packaging them together for everyone).

For the NVidia plugins? All of them?

Hello, When should we expect a new version of Flex + Unreal Engine 4 to deform objects? As I understand the current version of Flex 1.0 does not support the deformation of objects

Flex 1.2 does support plastic deformations if thatā€™s what you mean (deformations that remember the shape). FleX integrations from 4.19 onwards are using 1.2 but the is that the integration itself doesnā€™t implement functionality atm. Functionality itself can be seen at FleX 1.2 SDK demos.

Thanks for your reply. I understand.

Thatā€™s right.
I watched the Flex 1.2 demo . is amazing.
It is a pity that the integration in Unreal Engine 4 is not built functionality.
But why wasnā€™t enabled ? :frowning: Do you think will be introduced in the future?
I am surprised that Unity3d has several variations of deformation of objects with memory retention, but Unreal Engine 4 has not been modified.

Surprisingly, I installed the 4.20 engine with flex, and it keeps showing me version 1.0

You can get the current UE4 flex to hold the soft body deformation. You just set particle velocity to zero. I donā€™t know what plastic deformation looks with flex. But was my first attempt at soft body collision using the zero particle velocity. watch?v=jhE_WlNhPps

Besides the current UE4 Flex missing the plastic deformation, itā€™s also missing the diffuse particles. Without the diffuse particles, all fluids look like jelly. Also Unity recently got Flex support as a plugin. Not sure how difficult it is, but hopefully UE4 will get the different gameworks as plugins in the future. Also it would be great to get the cpu/non-cuda version of Waveworks.

I donā€™t know how you did it.

Add velocity option = 0 + damping 1000 ? , but I canā€™t make the particles move. How did you get the car to move with the particles? Is it Cloth, Soft body?

My experiment. Not flex. These are bones, but method is very long and hard, and not realistic.
v=vqIq2gaRvC0https?v=MRmGQx10ur4

Tell me how you did it ?

@ElizzaRF Your work is impressive. I saw it on reddit and I thought your work was using Flex.

Anyone can test soft body deformation ability immediately in Flex example map, called flexMixed. Press key V to hold particle movement. Then just walk into the various flex objects to see them move/deform to player collision.

In my opinion, Flex soft body is not best solution for full simulation of vehicle collisions. Maybe experienced coder or programmer can improve it or find solution. If Flex plastic deformation was enabled for UE4, then it could be good solution.

For my Flex vehicle collision test, I used the ue4 basic vehicle template from the editor, made the vehicleā€™s mesh hidden in game and shrunk down the collision boxes. I added a flex component to the vehicle BP and made a flex soft body from a copy of the vehicle mesh.

And I tweaked a bunch of settings. Most important is Flex Soft Container, I set velocity to 0. Sleep threshold 300.

But there is some visual glitches and other issues because flex soft body was not designed to work way. Plastic Deformation of Rigid Body is correct solution (Maybe).
Big is I cannot find way for more than one Flex Containers to interact. So vehicle flex body does not have collision with other flex objects, except for objects using same flex container. And flex particles do affect UE4 physics.

If you or anyone find improvements or solution please share :slight_smile:

If I succeed, I will write.

Youā€™re right, I saw freezing particle objects in the demo. Iā€™ll try and write. That sounds promisingā€¦

Prototype based on project https://vimeo/152619829. The Internet is open source.
Maybe in the future, when I have time, I can release a tutorial on how to achieve .
But is a very complex method of solution, as it has many problems. I am looking for new methods of solving physical collisions

Thanks for the information!!!:):):slight_smile:

Oh wow, I didnā€™t even consider :smiley: Tbh, I havenā€™t checked how FleX SDK demos do so canā€™t tell if itā€™s anything similar, freezing the velocities manually doesnā€™t sound what such feat should do tho even when it has similar outcome.

Hi, are there any information about Hairwork in ue 4.20 ? :slight_smile:

I just tried with kostenickjā€™s branch at and in the sample scenes it seems to work like a charm - huge thanks!

Note: I also build UnrealLightmass

But my branch has some other changes to skeletal mesh you might want to discard.

Hi, I use hairwork in my project, export and etc. work but i have problem with collisions. I use Polygon and i test shpere but in UE4 nothing works :frowning: Please help me :slight_smile:

I wouldnā€™t be that concerned about it, almost same happened at 4.18 but Nvidia did eventually release some of the branches for it. When I released 4.18-GameWorks merge originally, I had to port many of the techs myself from 4.17. But then again we got versions for almost every tech for 4.19.

I guess itā€™s especially because of architecture change in 4.20 why it takes longer time:


Change 3932819 by .Wright
[Integrate] Scene Textures uniform buffer * Base Pass Uniform Buffer now contains a Scene Textures uniform buffer. Previously the translucent base pass had to check ~40 loose scene texture parameters every draw.
  * FMeshMaterialShader's must now bind PassUniformBuffer and supply a valid pass uniform buffer. For most passes  is just FSceneTextureUniformParameters.
* FRendererModule::DrawTileMesh can now cleanly set dummy scene texture resources, just by configuring how the pass uniform buffer is created.
* Moved scene texture shader functions out of Common, into SceneTexturesCommon which must be manually included by shaders that want to use them
* Separate Mobile Scene Textures uniform buffer to silo the platform complexities
  

Iā€™m currently looking into merging VXGI into 4.20 based on your fork (again, thanks for a beautiful and clean merge work!), but itā€™s far from trivial, even more so since Iā€™m just starting with UE engine internals. From working with the code in the last couple of days I got the impression that more architecture changes like that are planned, so if Iā€™d be NVIDIA, Iā€™d wait until Epic has finished these changes to the rendering system before adopting their branches to a new engine version. Otherwise theyā€™d have to do it twice, and nobody likes to do that.

@HaBe2305 thanks for the PR, that must have taken a long time to make :slight_smile: I do agree that the end result is more readable and more informative but I actually try to avoid fixing the original formatting on purpose: Itā€™s way easier to track the changes on commits when you minimize all your own changes to the code base (and easier to merge the same changes into future engine versions if needed as you get less merge conflicts). I usually donā€™t even fix bad indentation for reason. I also sometimes deliberately remove Nvidiaā€™s additional formatting so that only relevant changes get in the individual tech merge and it stays more readable on the individual commits.

Therefore Iā€™m sorry to say that while your PR would make the code a lot more readable, Iā€™ll not be merging it for the reasons mentioned . I hope you understand :slight_smile:

Also one additional point to be made about the change comments: while they are handy to note that some GW tech has changed something there, the changes arenā€™t all additions. Sometimes the notes could make you think you could omit the code if you donā€™t use the related tech where in reality that would just break the thing. Properly commenting all edge cases like would take a long time as Nvidia usually doesnā€™t do it.