Announcement

Collapse
No announcement yet.

NVIDIA GameWorks Integration

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by SteveElbows View Post
    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?
    You are right. Since we don't have Batman Arkham series grade soft bodies and dynamic smoke, UE4 is CPU only then. Seems destructibles and cloth (I never used this before) can go without GPU acceleration.

    Bleh, my fault. I forgot that PhysX is CPU only in Unreal, or at least not fully supported in the official branch. Well, Flow will likely remove the dynamic smoke part of the main PhysX. Yeah, Ultimately it comes down to CUDA. Because for a moment I thought like a game dev, and not somebody who would use GP-GPU accelerated APIs to eradicate the competition via a UE4 github branch... -.-

    Meaning while AMD still thinks that open source is going to save their sorry human behind...

    My popcorn is ready...

    Comment


      Originally posted by Chariots
      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?
      Personally I've found that by far the largest impact on the performance is the stack levels, but only if you know how they work. Essentially it's similar to cascaded shadow maps. The amount of stacks is similar to the amount of cascades, and the range increases the distance of the effect, but lowers the resolution. So if you have one stack level and a range of 2000 you will have long range gi, but it will be low resolution. So if you want the highest quality possible, you need a low range and high stacks. But if you want performance, it starts acting strange. If you change the stack levels from 1 to 2, you will notice a massive dip in performance, supposedly because the system calculating the stacks is disabled when set to 1. But if you increase the stack levels from 2 to 3, then you will not have a very noticeable performance hit. From there it scales worse and worse. Also when you are at a low stack count (1-3) range has almost no effect on performance. The final piece to this is that the less stack levels you have, the less of a performance impact you will have from increasing the map size. So if you only have 2 stack levels, increasing the map size to 256 is a viable option.

      So, this is what I've found works best for optimizing VXGI.
      First, set your stack levels down to one, and increase the range until the voxelization reaches as far as you need for it to.
      Once you get the range you want, start whittling down the size of the voxels until you are happy with the results. First mess with the map size. Default is 128, so while you are at 1 stack with a high range, try increasing the map size to 256 and see if that is good enough. If it's still not high enough resolution, then set the map size back down to 128, and add a stack level. With the extra stack level, you can lower the range a little bit more to shrink the voxels. If you still aren't at a high enough quality, try increasing the map size to 256 again, then try lowering it and adding a stack again. Keep doing this process until you reach a good balance between quality and performance.

      What I've found from doing this is that the sweet spot is usually 2 stack levels, a map size of 256, and a range of 1200 to 1600 on my 980ti. Lowering the map size to 128 and keeping those settings the same scales all the way down to a 770, and possibly a bit further. Keep in mind that this is also with multibounce and specular tracing enabled. Turning those off can give an even further boost and still hold moderately high quality. There are of course many, many more settings that you can use to further optimize VXGI, but this is what I've found to be the fastest and most effective method.
      Last edited by Blakblt; 07-20-2016, 02:31 PM.

      Comment


        Originally posted by Chariots
        [MENTION=26427]B[/MENTION]lakbit That's very good info thank you. Will definitely try these.

        I'm not sure if this was written here before, but with 84 pages it is difficult to find performance tips. Maybe VXGI should get its own thread or something?
        Yeah that would probably be a smart idea. I've been following the development of VXGI in Unreal for at least a year now, and finding what you need in here can be hell. My trick for optimizing VXGI is just something that I figured out after messing with it as a hobby for months on end, and personally what I've found is that VXGI has the potential to either run as fast as SVOTI or mimic the quality of baked lighting. For better or worse, the default aims towards the latter, and the only way to fix that is to do some digging into the console commands. Don't let anyone fool you; VXGI is game ready. But without proper documentation, finding simple tricks like the one I posted comes down to having tons of time to kill, and a little bit of luck. That being said, another trick/bug I found a few months ago is that the in-editor performance can be significantly worse than the standalone performance. I've found that even in simple scenes running a standalone version of your project can shave off 2ms, and in some projects that seem unplayable in editor (reflection subway is a fantastic example), the difference can be far more drastic.

        Comment


          Originally posted by Chariots
          Maybe VXGI should get its own thread or something?
          I have setup a new thread for the VXGI integration as it has been requested numerous times now, you can find it here: https://forums.unrealengine.com/show...n&goto=newpost

          I have also notified Alexey of this thread, so hopefully new updates/responses will go there.
          NVIDIA GameWorks merged branch (v4.9.2) (v4.12.5) (v4.13 p2)
          Feel free to Donate if you wish to support me

          Comment


            Originally posted by SouldomainTM View Post
            Meaning while AMD still thinks that open source is going to save their sorry human behind...

            My popcorn is ready...
            This is one reason why i use AMD cards as they do not use "North Korea" like control and even block using open drivers by signing.
            tox.chat - Skype alternative
            blender.org - 3D suite

            Comment


              Originally posted by dkloving View Post
              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.
              The VXGI lightmap baking option is purely hypothetical at this point, as far as I know. This is a known request, but the implementation in UE4 is probably nontrivial, although VXGI has the facilities required to implement it. Doing that in runtime is even more complicated because lightmaps are static in UE.

              If your scene is mostly static, VXGI integration can be modified to skip most of the scene voxelization on every frame. For simplicity, the current UE integration configures VXGI to invalidate and update everyrhing on every frame, but that's not absolutely necessary. For a static scene with *no* multi-bounce lighting, both opacity and emittance textures can be preserved between frames, with only incremental updates caused by camera movement. Implementing this mode requires building a list of objects and lights that have been modified since the previous frame, and applying finer culling to the voxelization passes.

              Regarding performance improvement, if you observe that "VXGI WS" time in "stat unit" output is a significant part of the frame, then yes, using incremental voxelization should give a noticeable improvement.

              Comment


                Originally posted by Alexey.Panteleev View Post
                *no* multi-bounce lighting
                So, with multibounce enabled it is required to update everything on every frame?

                incremental updates caused by camera movement.
                Why does camera movement necessitate updates? Is it any movement, or only some conditions?


                Thanks for your help- I really appreciate it!

                Comment


                  Originally posted by dkloving View Post
                  So, with multibounce enabled it is required to update everything on every frame?



                  Why does camera movement necessitate updates? Is it any movement, or only some conditions?


                  Thanks for your help- I really appreciate it!
                  Multibounce lighting is achieved by voxelizing all geometry and adding indirect lighting from the previous frame to direct lighting. So, it only works correctly when you voxelize all geometry on every frame, and each frame adds a bounce. If you make incremental updates, there will be noticeable changes in lighting: some areas will have more bounces than others. And by areas I mean axis-aligned boxes in voxel space, so there will be sharp boundaries between areas updated more or fewer times.

                  Not every camera movement requires updates. The reason why updates are required at all is that the voxel clip-map covers a limited range of world space. When you move the camera (or rather, the anchor point which is normally somewhere in front of the camera) enough to change the position of the clip-map, regions in world space that were not covered before will need to be filled by voxelization. Moreover, there are multiple levels of detail in the clip-map, each covering a different range of world space, and they move together, so a single change in clip-map position triggers updates to all the levels.

                  Comment


                    Hello GalaxyMan I have tried with no luck to get your merged branch v4.9.2 working , every thing complies correctly but when i go to launch the editor i get this error:

                    Access violation - code c0000005 (first/second chance not available)

                    ""

                    nvcuda
                    nvcuda
                    nvcuda
                    nvcuda
                    APEX_TurbulenceFSPROFILE_x64
                    APEX_TurbulenceFSPROFILE_x64
                    APEX_TurbulenceFSPROFILE_x64
                    APEX_TurbulenceFSPROFILE_x64
                    APEXFrameworkPROFILE_x64
                    APEXFrameworkPROFILE_x64
                    UE4Editor_Engine!FPhysScene::InitPhysScene() [d:\unreal_n\engine\source\runtime\engine\private\physicsengine\physscene.cpp:1688]
                    UE4Editor_Engine!FPhysScene::FPhysScene() [d:\unreal_n\engine\source\runtime\engine\private\physicsengine\physscene.cpp:153]
                    UE4Editor_Engine!UWorld::CreatePhysicsScene() [d:\unreal_n\engine\source\runtime\engine\private\world.cpp:3357]
                    UE4Editor_Engine!UWorld::InitWorld() [d:\unreal_n\engine\source\runtime\engine\private\world.cpp:866]
                    UE4Editor_Engine!UWorld::InitializeNewWorld() [d:\unreal_n\engine\source\runtime\engine\private\world.cpp:1068]
                    UE4Editor_Engine!UWorld::CreateWorld() [d:\unreal_n\engine\source\runtime\engine\private\world.cpp:1144]
                    UE4Editor_Engine!UEngine::Init() [d:\unreal_n\engine\source\runtime\engine\private\unrealengine.cpp:799]
                    UE4Editor_UnrealEd!UEditorEngine::InitEditor() [d:\unreal_n\engine\source\editor\unrealed\private\editorengine.cpp:431]
                    UE4Editor_UnrealEd!UEditorEngine::Init() [d:\unreal_n\engine\source\editor\unrealed\private\editorengine.cpp:586]
                    UE4Editor_UnrealEd!UUnrealEdEngine::Init() [d:\unreal_n\engine\source\editor\unrealed\private\unrealedengine.cpp:49]
                    UE4Editor!FEngineLoop::Init() [d:\unreal_n\engine\source\runtime\launch\private\launchengineloop.cpp:2101]
                    UE4Editor_UnrealEd!EditorInit() [d:\unreal_n\engine\source\editor\unrealed\private\unrealed.cpp:63]
                    UE4Editor!GuardedMain() [d:\unreal_n\engine\source\runtime\launch\private\launch.cpp:133]
                    UE4Editor!GuardedMainWrapper() [d:\unreal_n\engine\source\runtime\launch\private\windows\launchwindows.cpp:126]
                    UE4Editor!WinMain() [d:\unreal_n\engine\source\runtime\launch\private\windows\launchwindows.cpp:200]

                    any help would be appreciated

                    Thank you

                    Comment


                      Originally posted by Alexey.Panteleev View Post
                      Multibounce lighting is achieved by (...)
                      Okay, this makes a lot of sense and explains the effect seen when turning multibounce on. So, when we make lighting changes, we could simply run a few updates of the scene and then stop to get multibounce?

                      When you move the camera (or rather, the anchor point which is normally somewhere in front of the camera) enough (...)
                      There is only one possible anchor point per scene right? We place a VXGI anchor in the middle of the scene, which I presume overrides the normal camera-located anchor? Our scenes are interior / room-scale, so this is workable for us.


                      I'm still interested in lightmaps as well. I have some strange ideas on things to do with that, and I think long-term its the best route for our project. Hopefully I can get the go-ahead to invest some time into it.

                      Comment


                        As of current state i ask is this VXGI have full source incuded or only some weird sdk type closed blobs? non-programmer here. Just interested of how much control people can have over VXGI.
                        tox.chat - Skype alternative
                        blender.org - 3D suite

                        Comment


                          Originally posted by dkloving View Post
                          Okay, this makes a lot of sense and explains the effect seen when turning multibounce on. So, when we make lighting changes, we could simply run a few updates of the scene and then stop to get multibounce?
                          If the anchor is static, yes, you could do that.

                          Originally posted by dkloving View Post
                          There is only one possible anchor point per scene right? We place a VXGI anchor in the middle of the scene, which I presume overrides the normal camera-located anchor? Our scenes are interior / room-scale, so this is workable for us.
                          Correct, there is only one anchor. When you place and enable VXGI Anchor component, you override the default one attached to the camera.

                          If the scene is completely static and the anchor is static too, you can hack the engine to stop doing all the voxelization calls after a few frames... the main problem here I guess would be to detect when you can do that.

                          Comment


                            Originally posted by AE_3DFX View Post
                            As of current state i ask is this VXGI have full source incuded or only some weird sdk type closed blobs? non-programmer here. Just interested of how much control people can have over VXGI.
                            VXGI library is currently closed source. The integration into UE4 is open.

                            Comment


                              Originally posted by Bladerskb
                              so is there a 4.12 build for VXGI?
                              Build - no, as usual, but there is integration source on GitHub that you can build.
                              https://github.com/NvPhysX/UnrealEngine/tree/VXGI-4.12

                              Comment


                                Originally posted by Alexey.Panteleev View Post
                                VXGI library is currently closed source. The integration into UE4 is open.
                                Thanks for info, if they ever open VXGI code but as of now there is even more reason to wait when AHR becomes better and better and/or EPIC selects best GI solution.
                                tox.chat - Skype alternative
                                blender.org - 3D suite

                                Comment

                                Working...
                                X