NVIDIA GameWorks Integration

[DiagaDumah]

Clothing is better left to APEX because there is more to clothing than a piece of cloth. Characters are generally animated with extreme motions that would challenge a cloth solver, so there are features built into APEX Clothing that manage the combination of animated and simulated behavior. APEX clothing does have inter-cloth collision; although it is expensive it is usable as it stands, and we will be improving the performance of cloth-cloth collision too.

--Mike

Hey Mike (or anyone who may be able to help),

I've been playing with the physX plug-in for Maya, and I'm currently using unreal 4.11. I have a situation very similar to the Wushu Demo from 2013 GDC (the main video on the download center page) with overlapping cloth on a character, and no matter what I do, I cannot seem to make them play together in the same way as that video. I have activated self collision, I have played with the self collison thickness, I have even played with backstop. No success. Do the overlapping cloth pieces need to be part of the same clothing Node to be able to talk to each other with self collision? Because I have tried making the overlapping cloth two "elements" of the same "mesh" and added to one cloth node, and that didn't work either. Or can multiple Nodes collide with each other? I'm completely stumped, and I don't know how to fix the problem.

[Mike.Skolones]

Hi,

I don't have personal experience with authoring clothing in UE4, but I'll bring your question to the attention of someone who does. The Wushu demo was done on a highly customized UE3 code base, it's very possible that the effect cannot be replicated with stock UE4.

--Mike

Hey Mike (or anyone who may be able to help),

I've been playing with the physX plug-in for Maya, and I'm currently using unreal 4.11. I have a situation very similar to the Wushu Demo from 2013 GDC (the main video on the download center page) with overlapping cloth on a character, and no matter what I do, I cannot seem to make them play together in the same way as that video. I have activated self collision, I have played with the self collison thickness, I have even played with backstop. No success. Do the overlapping cloth pieces need to be part of the same clothing Node to be able to talk to each other with self collision? Because I have tried making the overlapping cloth two "elements" of the same "mesh" and added to one cloth node, and that didn't work either. Or can multiple Nodes collide with each other? I'm completely stumped, and I don't know how to fix the problem.

[DiagaDumah]

Hi,

I don't have personal experience with authoring clothing in UE4, but I'll bring your question to the attention of someone who does. The Wushu demo was done on a highly customized UE3 code base, it's very possible that the effect cannot be replicated with stock UE4.

--Mike

I really appreciate the help, thank you so much. I've been running into this wall for a while now, if you happen to talk to someone who might know what I can do, that would be fantastic. Thank you for your time!

[azoellner]

Hi DiagaDumah,
I actually authored the wushu demo so I can answer your questions. Ultimately the asset was broken down into multiple parts, the hood, shirt, skirting, and pants. I did this so that I could have different settings per section of clothing. I got 90-95% of the collision effect between those asset with a careful balance between max distance, backstop and collision shapes. We knew the hood, and shirt were unlikely to collide with anything so those stayed very independent. The pants and the skirting has are where the tricks are. The pants are mainly small max distance near the bottoms and used backstop for the inner leg collision. the only collision shape that was used was for the foot, and it was exaggerated in size if my memory serves me well. The skirting had enlarged collision shapes. The size of the collision shapes was about at the distance of the max distance for the pants, give or take a nudge either way. The max distance on the skirting was greater near the bottoms and tighter closer to the waste line. The hood, skirting, and sleeves all used their own self collision. This helped the fold size on the hood and sleeves and helped with the 4 pieces of skirting from interpenetrating. The other two big notes are to use local space sim, it handles fast animation much better, and turning the inertia blend up a bit. Also use the connected spheres for collision shapes. They can conform to the body better and more efficient with clothing. As an alternative, you could always combine all your cloth into one asset and use self collision if your vert count isn't to high and doesn't over complicate other authoring matters too much. I hope this helps to get you the results you are looking for.

[emanuel.may]

I tried VXGI on a marketplace demo scene (specifically Pirates Island, because I had it lying around). I used lowest amount of cones possible, and lowest voxel resolution possible (32). With VXGI off I get 8.33ms on GPU (120 FPS, capped basically), with it on I get 28ms on GPU (37FPS). Meaning a 20ms cost on gtx970, on a scene that isn't really that full.

Am I missing something here? CryEngine SVOTI is seems to be accurate to their doc claims of 2-4ms on gtx780. I don't expect to get their level of performance as they are using other techniques like light probes, but nearly 5 times the cost seems a bit off.

Are there any other settings I'm not aware off? If I halve the range, it maybe shaves off 6-7ms at most, but it becomes extremely noticeable immediately, so that's a no go it seems. What gives?

No you don't miss something, VXGI is by far not comparable to SVOTI or Enlighten if it comes to performance. That's the reason why everyone is getting more and more annoyed about UE4 not having a reliable dynamic GI solution that is usable in the more complex scenes that most games tend to have. Don't get me wrong: VXGI is awesome for what it is. But right now it's mainly usable for making nice scenes for a portfolio, making movies or for ArchViz stuff. If you have a very simple game with very limited scenes, it might also still be fast enough (if you can control the hardware it runs on), but for most real games it's just too slow. We experimented with different GI solutions (both abandoned solutions by Epic and the WIP community solution) for UE4 and VXGI is still the best in the bunch. But in the end we decided not to use it, because it was limiting our game too much, even for an optional high-end feature.

We still have hope there will be some big performance improvements in the future (maybe even something like partial baking or specific "voxelization probes") but right now it's not usable for us.

[SteveElbows]

I note with excitement that Nvidia Flow is starting to get more of an official mention on the nvidia site now. eg its actually linked to from the visual FX menu on the GameWorks site, with mention of a beta in July and UE4 integration in Q3.

https://developer.nvidia.com/nvidia-flow

[olek]

flow seems to be already integrated. just have a look at the new nvidia vr app http://store.steampowered.com/app/46..._7_7_230_150_1 its build with ue4

[DiagaDumah]

Hi DiagaDumah,
I actually authored the wushu demo so I can answer your questions. Ultimately the asset was broken down into multiple parts, the hood, shirt, skirting, and pants. I did this so that I could have different settings per section of clothing. I got 90-95% of the collision effect between those asset with a careful balance between max distance, backstop and collision shapes. We knew the hood, and shirt were unlikely to collide with anything so those stayed very independent. The pants and the skirting has are where the tricks are. The pants are mainly small max distance near the bottoms and used backstop for the inner leg collision. the only collision shape that was used was for the foot, and it was exaggerated in size if my memory serves me well. The skirting had enlarged collision shapes. The size of the collision shapes was about at the distance of the max distance for the pants, give or take a nudge either way. The max distance on the skirting was greater near the bottoms and tighter closer to the waste line. The hood, skirting, and sleeves all used their own self collision. This helped the fold size on the hood and sleeves and helped with the 4 pieces of skirting from interpenetrating. The other two big notes are to use local space sim, it handles fast animation much better, and turning the inertia blend up a bit. Also use the connected spheres for collision shapes. They can conform to the body better and more efficient with clothing. As an alternative, you could always combine all your cloth into one asset and use self collision if your vert count isn't to high and doesn't over complicate other authoring matters too much. I hope this helps to get you the results you are looking for.

Hi azoellner,
Thank you so much for all of this information, I really appreciate it! I've started testing this right away, and already I'm seeing better results! I just wanted to clarify two things, how do I activate local space sim? I don't seem to see it anywhere in the node settings in Maya. And for the skirting in the wushu model, were all the overlapping cloth pieces (4 in total it looked like?) of the skirt, together on the same node? and you just activated self collision to keep them apart? Thank you again for your help, this is huge!

[dkloving]

I'm working on a project that is a mostly-static "experience" sort of thing. IE, the user has freedom to move around but we only rarely update lighting/geometry/materials. VXGI has been amazing, and we are absolutely shipping with it (we control the hardware). My understanding of VXGI is far from complete, but I'm hoping to increase performance and had a couple of ideas...

Since we only update things that affect lighting rarely, it seems like we could decouple some of the heavy lifting. Page 26 mentions using arbitrary shaders for building lightmaps. Has anyone experimented with this in UE4? Rather than baking with lightmass, we could do a fairly quick re-bake whenever we want to at runtime.

But what about something simpler- could we split the VXGI pipeline so that we only run parts when lighting needs to be updated? Would this even give a meaningful performance improvement?

My background is mostly computer vision and CUDA, so a lot of the this is really unfamiliar territory for me.

[SouldomainTM]

I note with excitement that Nvidia Flow is starting to get more of an official mention on the nvidia site now. eg its actually linked to from the visual FX menu on the GameWorks site, with mention of a beta in July and UE4 integration in Q3.

https://developer.nvidia.com/nvidia-flow

Sounds like that Nvidia Flow is going to appear in the preview of 4.13.

[SteveElbows]

Sounds like that Nvidia Flow is going to appear in the preview of 4.13.

None of the other nvidia GameWorks stuff has been integrated into the standard official UE4 branch or launcher version of UE4 before now. So without specific, explicit confirmation that it will be different this time, I'd assume that nvidia flow release schedule doesnt have much to do with UE4's own release schedule at all. And we will still have to compile our own version from source.

Having said that I think nvidia have said they will release the VR Funhouse UE4 project to encourage people to use UE4. But again unless I hear otherwise I'm going to assume that this will also involve a custom branch of UE4 being used, eg one with Flow and FleX included or whatever GameWorks modules were actually used in Funhouse.

[SouldomainTM]

None of the other nvidia GameWorks stuff has been integrated into the standard official UE4 branch or launcher version of UE4 before now.

It's called Nvidia PhysX. It it part of the Unreal engines for a very long time now. Nvidia and Epic Games do have a closer relation to each other than one may think. The question is what Nvidia is really thinking. Because if Nvidia played according to the rules of Epic Games, all of the GameWorks stuff may end up being a core part of UE4.

UE4 is the perfect engine for all that GameWorks stuff. And that's also good for Epic, because they won't have to implement everything all over again. Epic Games is very rich. Maybe they should go for some shopping? Micro$oft likes to go shopping, a lot...

I just can't help but to wonder about CUDA though. Because I think Flow requires a GP-GPU grade acceleration. Meaning if one (Epic Games) wanted to run it on AMD cards, one would require to support OpenCL.

[azoellner]

Hi azoellner,
Thank you so much for all of this information, I really appreciate it! I've started testing this right away, and already I'm seeing better results! I just wanted to clarify two things, how do I activate local space sim? I don't seem to see it anywhere in the node settings in Maya. And for the skirting in the wushu model, were all the overlapping cloth pieces (4 in total it looked like?) of the skirt, together on the same node? and you just activated self collision to keep them apart? Thank you again for your help, this is huge!

Hi, Local space I believe is a check box in Ue4 and I think it is defaulted off. You will have to check to confirm. In the DCC plugins, local space is on by default and not exposed. You use the Inertia Blend control to blend in world motion influence. And the 4 flaps on the skirting were all in the same asset. I gave them some breathing room in the bind pose as well. If they are too close and self collision radius is larger than the separation of the cloth segments, it may not behave so well. So yo have to strike a balance there. I hope this helps.

[DiagaDumah]

Hi, Local space I believe is a check box in Ue4 and I think it is defaulted off. You will have to check to confirm. In the DCC plugins, local space is on by default and not exposed. You use the Inertia Blend control to blend in world motion influence. And the 4 flaps on the skirting were all in the same asset. I gave them some breathing room in the bind pose as well. If they are too close and self collision radius is larger than the separation of the cloth segments, it may not behave so well. So yo have to strike a balance there. I hope this helps.

Perfect! Thank you so much! This helps a ton, and I will get to testing it right away. Thank you!

[SteveElbows]

It's called Nvidia PhysX. It it part of the Unreal engines for a very long time now. Nvidia and Epic Games do have a closer relation to each other than one may think. The question is what Nvidia is really thinking. Because if Nvidia played according to the rules of Epic Games, all of the GameWorks stuff may end up being a core part of UE4.

UE4 is the perfect engine for all that GameWorks stuff. And that's also good for Epic, because they won't have to implement everything all over again. Epic Games is very rich. Maybe they should go for some shopping? Micro$oft likes to go shopping, a lot...

I just can't help but to wonder about CUDA though. Because I think Flow requires a GP-GPU grade acceleration. Meaning if one (Epic Games) wanted to run it on AMD cards, one would require to support OpenCL.

Even though PhysX now comes under their GameWorks brand, its in a different league of integration with many engines, not like all the other GameWorks stuff that this thread is about. And I'm not sure the GPU-accelerated version of PhysX (as opposed to CPU) has been so sucessfully integrated into engines like UE4?

Some of the GameWorks modules only work on nvidia hardware, eg FleX, so I can see why those arent going to be integrated into the main branches of UE4. As far as I can tell from the nvidia site flow is not like that and will work on other manufacturers hardware. So for Flow at least I think the issues preventing main branch integration are often something other than purely technical.