Announcement

Collapse
No announcement yet.

NVIDIA GameWorks Integration

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

  • replied
    Hey 0lento thank you very much for maintaining your repos of Gameworks features!

    We recently updated to 4.21 and merged your HBAO+ version for 4.21 into our engine as well. Unfortunately since then we have the problem that the AO seems to be leaking from the main viewport into all other editor viewports, which is very visible in other editor preview screens. I am not sure why this would happen at the moment, but I suspect the change for forward-rendering might be the culprit. Probably only one RenderTarget is used for all Viewports, but I don't find the issue so far. Any idea how we can solve this?

    Btw this also happens with any of the Sample projects in your HBAO+VXGI+TXAA branch. Just enable HBAO+ and open two screens. The AO from the main viewport should leak into the other viewports.

    I would appreciate any help

    Leave a comment:


  • replied
    Is it possible to activate or spawn Flex shape emitters in game? I tried, but the editor crashes with an error message:

    [2019.05.03-08.55.38:084][770]LogWindows: Error: === Critical error: ===
    [2019.05.03-08.55.38:084][770]LogWindows: Error:
    [2019.05.03-08.55.38:084][770]LogWindows: Error: Assertion failed: Container->IsMapped() [File:C:\git\UnrealEngine\Engine\Plugins\GameWorks\Flex\Source\Flex\Private\FlexParticleEmitterInstance.cpp] [Line: 82]

    When looking at that line in the source code, it looks like this is the expected behaviour.

    What I want to do is have a shape emitter being ready, and when an event happens it spawns the particles. I then want to be able to invoke the same spawning again multiple times.
    Funny thing is that it works if I do it in the editor by having the checkbox "Auto Activate" unchecked when the game starts, then pause the game and check it. This works exactly the way I want, but I can't get it to work from a blueprint script.

    Leave a comment:


  • replied
    Originally posted by 0lento View Post
    Thanks for the help! Unfortunately that seems to be above my capabilities right now, hopefully I'll get the opportunity to pass your advice onto someone more capable in my workplace.

    Leave a comment:


  • replied
    Originally posted by wickerman123 View Post

    Are there any steps I can follow to do the merge myself? It's not something I've ever done.
    See this post: https://forums.unrealengine.com/comm...34#post1559934

    Leave a comment:


  • replied
    Originally posted by 0lento View Post
    I never included AudioWorks on my merges mainly because it only runs on Nvidia Maxwell+, AMD users can't use it. I wouldn't expect updating it to be difficult as long as the old audio system and it's audio framework structure isn't changed radically in UE4.
    Are there any steps I can follow to do the merge myself? It's not something I've ever done.

    Leave a comment:


  • replied
    Originally posted by wickerman123 View Post
    Has anyone here got a build of AudioWorks in a later version of the engine? The Github repo is ancient and is built for 4.15.

    I have next to no experience with Visual Studio but I had a quick look at the project and it seems that only 2-3 base classes have been changed and the rest is third party dependencies. Surely this makes it a lot less difficult to update to a newer version like 4.21? If that's the case, are there any guides on merging/updating that I can follow?
    I never included AudioWorks on my merges mainly because it only runs on Nvidia Maxwell+, AMD users can't use it. I wouldn't expect updating it to be difficult as long as the old audio system and it's audio framework structure isn't changed radically in UE4.

    Leave a comment:


  • replied
    Has anyone here got a build of AudioWorks in a later version of the engine? The Github repo is ancient and is built for 4.15.

    I have next to no experience with Visual Studio but I had a quick look at the project and it seems that only 2-3 base classes have been changed and the rest is third party dependencies. Surely this makes it a lot less difficult to update to a newer version like 4.21? If that's the case, are there any guides on merging/updating that I can follow?

    Leave a comment:


  • replied
    Originally posted by wangxihappyhappy View Post

    I packaged the waveworks tester too and encountered the same problem. Did you find and solution?

    It was solved in 4.19.

    Leave a comment:


  • replied
    Originally posted by 황용수 View Post
    Hi! everyone..

    I have a trouble..

    Now i am testing nvidia waveworks.

    When i tested in Editor, it was successful.
    but i packaged program, it was crash.

    I think it was relative with shader, because i met this error message.

    ----------------------------------------------------------------------------------------------------------------------------------------------------------------
    LoginId:aab2f45649d338800007d6ae6e72db2a
    EpicAccountId:2d7fa9ae0b134dc98fea1542a7cbf458

    Assertion failed: (Index >= 0) & (Index < ArrayNum) [File:F:\UnrealEngine-4.18.3-release\Engine\Source\Runtime\Core\Public\Containers/Array.h] [Line: 610] Array index out of bounds: 0 from an array of size 0

    Wave_Win64_DebugGame!FDebug::AssertFailed() [f:\unrealengine-4.18.3-release\engine\source\runtime\core\private\misc\assertionmacros.cpp:414]
    Wave_Win64_DebugGame!TBasePassWaveWorksDrawingPolicy<FUniformLightMapPolicy>::ConfigureQuardTreeInputMapping() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\basepassrendering.h:1420]
    Wave_Win64_DebugGame!TBasePassWaveWorksDrawingPolicy<FUniformLightMapPolicy>::TBasePassWaveWorksDrawingPolicy<FUniformLightMapPolicy>() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\basepassrendering.h:1515]
    Wave_Win64_DebugGame!FDrawTranslucentMeshAction::Process<FUniformLightMapPolicy>() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\translucentrendering.cpp:491]
    Wave_Win64_DebugGame!ProcessBasePassMesh<FDrawTranslucentMeshAction>() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\basepassrendering.h:2080]
    Wave_Win64_DebugGame!FTranslucencyDrawingPolicyFactory:rawWaveWorksMesh() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\translucentrendering.cpp:718]
    Wave_Win64_DebugGame!FTranslucencyDrawingPolicyFactory:rawDynamicWaveWorksMesh() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\translucentrendering.cpp:795]
    Wave_Win64_DebugGame!FTranslucentPrimSet::RenderWaveWorksPrimitive() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\translucentrendering.cpp:1106]
    Wave_Win64_DebugGame!FTranslucentPrimSet:rawWaveWorksPrimitives() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\translucentrendering.cpp:1003]
    Wave_Win64_DebugGame!FDeferredShadingSceneRenderer::RenderWaveWorks() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\translucentrendering.cpp:1771]
    Wave_Win64_DebugGame!FDeferredShadingSceneRenderer::Render() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\deferredshadingrenderer.cpp:1260]
    Wave_Win64_DebugGame!UpdateSceneCaptureContentDeferred_RenderThread() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\scenecapturerendering.cpp:267]
    Wave_Win64_DebugGame!UpdateSceneCaptureContent_RenderThread() [f:\unrealengine-4.18.3-release\engine\source\runtime\renderer\private\scenecapturerendering.cpp:309]
    Wave_Win64_DebugGame!TGraphTask<TEnqueueUniqueRenderCommandType<`FScene::UpdateSceneCaptureContents'::`12'::CaptureCommandName,<lambda_2f5b22162577ad8db4efab9192d8d401> > >::ExecuteTask() [f:\unrealengine-4.18.3-release\engine\source\runtime\core\public\async\taskgraphinterfaces.h:787]
    Wave_Win64_DebugGame!FNamedTaskThread::ProcessTasksNamedThread() [f:\unrealengine-4.18.3-release\engine\source\runtime\core\private\async\taskgraph.cpp:651]
    Wave_Win64_DebugGame!FNamedTaskThread::ProcessTasksUntilQuit() [f:\unrealengine-4.18.3-release\engine\source\runtime\core\private\async\taskgraph.cpp:560]
    Wave_Win64_DebugGame!RenderingThreadMain() [f:\unrealengine-4.18.3-release\engine\source\runtime\rendercore\private\renderingthread.cpp:327]
    Wave_Win64_DebugGame!FRenderingThread::Run() [f:\unrealengine-4.18.3-release\engine\source\runtime\rendercore\private\renderingthread.cpp:461]
    Wave_Win64_DebugGame!FRunnableThreadWin::Run() [f:\unrealengine-4.18.3-release\engine\source\runtime\core\private\windows\windowsrunnablethread.cpp:76]
    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    I don't know solution. Pleas help me.
    I packaged the waveworks tester too and encountered the same problem. Did you find and solution?

    Leave a comment:


  • replied
    Hi YONI_G


    I think those quotes may answer your question:


    Originally posted by 0lento View Post

    No plans, hoping Nvidia will upgrade it at some point.
    that's because:

    ​​​​​​​
    Originally posted by ax448 View Post
    By the way 0lento , I imagine that at this point UE 4.22's rendering backend has changed so much that there's not much of a possibility of VXGI2 ports to 4.22 and up unless Nvidia update their branch, right? Though I suppose it's pretty much invalidated by the presence of RT creeping into UE anyhow.

    I guess I'll have to start messing around with RT in UE once nvidia pushes out those DXR drivers sometime now in April.
    (For anyone unaware: Nvidia is pushing a GTX Raytracing driver sometime now in April, which'll enable DXR on older Gpus. ( 1060 6GB and stronger, basically. )
    Which will let us use the RT features in unreal, though massively slower than on a RTX card. )
    Originally posted by 0lento View Post
    This is a valid concern. I'm afraid it might affect other GW techs too, not just VXGI and Nvidia has pretty much dropped the ball for these integrations lately. I hope they can start updating them again.

    Leave a comment:


  • replied
    Any plans to include Flex in this soon?
    <<
    11-29-2018, 03:38 PM
    Just pushed out update for merged 4.21 GameWorks: https://github.com/0lento/UnrealEngi...4.21-GameWorks

    This repo contains following GameWorks techs:
    - Blast 1.1.4
    - Flow 1.0.1
    - HairWorks 1.4
    - HBAO+ 4
    - TXAA 3
    - VXGI 2.0.1

    I've tested most of the techs to work fine on sample projects using both editor and packaged development builds so things should be in order but do report if you have issues with it.
    Last edited by 0lento; 03-11-2019, 10:09 AM.
    https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)
    >>

    Leave a comment:


  • replied
    The roadmap on trello has been updated with info showing that Niagara and Chaos integration is done for UE 4.23 although as per previous announcement we know it still is beta stage until 4.24 later on:


    https://trello.com/c/i51lp6R5/389-ni...-chaos-physics

    https://trello.com/c/naYvhUWj/387-gp...n-enhancements

    Leave a comment:


  • replied
    Nvidia released their Isaac SDK integration for UE 4.20 here: https://github.com/NvPhysX/UnrealEng...e/IsaacSim_1.2

    It's more focused about robotics, more info here: https://developer.nvidia.com/isaac-sdk

    What is interesting about this fork though is that it does come with PhysX 4 integration for UE4, including option to use the new TGS solver and also with Robot Builder plugin which implements PhysX articulations.

    The huge bummer on this all is that the Isaac SDK itself contains this super restrictive license that prevent you from doing any benchmarking or competitive analysis related to the SDK without Nvidia's permission and simply doesn't allow you to use the SDK at all if there's no Nvidia GPU on the system.

    Since the restriction apply to Isaac SDK, this limits out the robotbuilder plugin too as it also uses isaac libraries in addition to implementing physx articulations. This is major letdown for all people who wanted to see PhysX articulations in UE4 as otherwise that part of the plugin could have been ported to be used even on stock UE4 without custom engine build. The PhysX4 integration itself is portable to custom ue4 branches without the Isaac SDK so I think that could be reused. PhysX 4 part of the Isaac repo is just modified ue4 code which goes under UE4 eula and PhysX 4 is under BSD license so that should be a nonissue licensing wise.
    Last edited by 0lento; 04-12-2019, 10:42 PM.

    Leave a comment:


  • replied
    Originally posted by 0lento View Post
    This is a valid concern. I'm afraid it might affect other GW techs too, not just VXGI and Nvidia has pretty much dropped the ball for these integrations lately. I hope they can start updating them again.

    I'm about to start a test run to check on how these techs look for 4.22 now, will see if I manage to get any of them in easily.
    if Nvidia and epic both do not update the hairworks plugins. is there any solution for dynamic hair simulation?
    in most CGI project which uses UE4 for rendering, the 'plane hair' is not good enough to the others.

    about the 4.22 rendering backend change. I tried to merge the old hairworks branch for 4.22, but it does not work. And I do not know there is or not some guide for this.

    Leave a comment:


  • replied
    Originally posted by script526 View Post

    I don't think the are going to get back to this. First of all, the told they're going to get back to this several times in forums about 3-5 years ago. Secondary, as far as I get this they think that all Gameworks stuff is not necessarily has to be userfriendly and being updated all the time. It seems to me, Gameworks is for advanced programmers who could take the product at any stage and easily change it for their needs. So, as long as we're not part of those we have to struggle or eventually refuse all their products as I did long time ago.
    Hmm yeah... I know what you mean...but hopefully you're wrong haha. There must be many UE4 devs using gameworks that are a bit stuck now... I mean if you are a AAA studio using Hairworks I'm sure you can get it working in any engine you want but I can't imagine there's that many devs able to use it now, unless they stick with older engine versions.

    Leave a comment:

Working...
X