Download

NVIDIA GameWorks Integration

My estimates are educated guesses from using UE4 for past 5 years, it never evolves as fast as you suggest. This is a completely new physics engine we are talking about, not some minor change (it took even several engine versions to get PhysX 3.4 upgrade stable with Unreal).

I just try to set people to have realistic expectations. :slight_smile:

Hey Olento can you tell me how to get wheel hit results from ue4’s wheeled vehicle wheels thru a c++ function library, like maybe a code snippet or something? I want to get surface material and at track and particle effects to it without additional traces. I mean if you can.

I don’t know if that’s exposed, I also don’t use wheeled vehicles, I’d start by checking the classes if they expose the hits but I doubt they do. You can just do linetraces yourself per wheel etc.

That offroad vehicle demo in the learn tab has the code for it.

I figured there would be a more efficient way, but i guess making line traces should work, I just wanted to use there existing traces. But Thanks guys.

Hello. I faced with problem that I can’t access to gameworks repository after linking GitHub and Epic accounts 1 week ago.

Hey guys,

Does anybody had problem with 0lento GameWorks builds?

This crashing every time I am opening large projects like Character Interaction, or maps from Soul: City, Soul: Cave.

Showing message: Array index out of bounds

You sure this is specific to the GW branch? Can you check if you get that same error on stock UE 4.21.2?

You have to be logged into that github account you linked to see the ue4 repos.

Thank you 0lento

Good question. I checked this in UE 4.21.2 from the stock, and it seems okay. All three (Character Interaction, Soul City, Soul Cave) passed the load test.
Also I had non GW custom build of UE 4.21, it worked fine too.

Just in case Soul City and Soul Cave are available for free at Marketplace, so it will be easy to reproduce.

Can you give more specific repro instructions? Just to make sure, you are running this on Windows, right? (Windows is requirement for GameWorks itself)

I just did fresh build for my 4.21-GameWorks and opened Soul: Cave with it. It worked fine in the editor without errors (I also opened all included maps with it just to make sure it’s not some specific level that triggers the error). It also worked fine when I packaged it with Shipping & 64-bit conf and ran the result in standalone so there’s not much I can do from my end unless you can give more specific repro case I’m afraid :confused:

edit: I originally opened Soul: Cave as a blueprint project. I now also tested Soul: City with c++ project as well but it works fine on my end too, all levels load up fine. Both tested on my 4.21.2 GameWorks branch.

Also, have you used the branch with or without WaveWorks? The branch I’m testing with now doesn’t have WaveWorks.

Hmm, that’s weird. I tested these in both with and without WaveWorks branches. I am running this on Windows 10. GameWorks test projects are running just fine.

The steps as below:

  1. Create a new project
  2. In the EPIC launcher add Soul: Cave into project. Select version as 4.21
  3. In the new project open Soul: Cave map
  4. At this point it will crash

This works fine for me. Are you building this on VS2017? VS2015 builds are super unstable on 4.20+ so if you use that, it could be one reason.

With 15.8 and before the 2017 is also producing bad code and the editor can random crash. So it’s better to use 15.9+ (update the vs) and clean build the solution.

I am building on VS2019. It builds pretty well, but I had to make a few changes:

  1. VCToolChain.cs got extra lines at line #463
    Arguments.Add("/wd4800");
    Arguments.Add("/wd5038");
  2. One of GameWorks files was complaining on std::string, so I had to add <string> into that file

Thank you for your help

Just in case. I had also custom non GameWorks build on VS2019, and the Soul: Cave was running just fine.
Currently Installing 2017, will see how it will react

To confirm 2017 build also has this issue.

Then I’m afraid it’s out of my hands. It works on my end without issues on both mentioned Soul samples and GW samples so I can’t repro this. Are you sure you are now trying to build completely unmodified version of my repo? You later on said you had bunch of changes on top, your issues could be caused by them. And you use the current version on the github and not some earlier one?

Anyway since I can’t repro this, best you can do it to debug the cause yourself - which you should do regardless as I’m not officially giving any support for these, these are just made available for people who want to use them.

One way to get proper callstack for this:

  • Make a empty UE4.21 c++ project with no starter content using the custom engine (or if you made it with Epic Launcher, after project creation, go to project folder, right click the uproject and use “switch engine version” option to swap the project to target the custom engine build)
  • Add the content that breaks it for you using Epic Launcher, be it that Soul:Cave or Soul:City
  • Open the projects sln file with Visual Studio, make sure UE4 is the default project there (seen in bold on the hierarchy tab), if it’s not default, you can set it by right clicking the project and set it to default startup project there
  • Once solution open on VS and default set to UE4, just hit the green play button (or use menu to start the thing with debugger attached), this will launch the UE4 editor with VS debugger attached. Also make sure you’ve haven’t changed the default build conf on this project sln, it defaults to “Development Editor” which is the right choice usually.
  • If it crashes, it will throw you back into VS at the moment of crash and you can examine the callstack. The topmost item you see is probably the array.h one but that’s just generic UE4 class that is not likely the cause of your issue, trace down the callstack and try to see what part of the code actually tries to use the array incorrectly.

@CRYOMEN Oh, just to verify, you are building the engine using the official UE4 build instructions and are using “Development Editor” as the build configuration? If you do full debug build for the whole engine, it will not likely work as I’ve not tested recent gameworks on this configuration + I think some user reported FleX etc had some issues on it (but that must have been on 4.20 as there’s no 4.21 FleX). I should probably try and fix that myself, it’s sourced from nvidias code as they most likely didn’t test that case either. In general even testing engine side debug builds thoroughly would be a pain as editor it’s really slow to run on my computer.

Edit: Tested Soul:City also with Debug build, works fine.

Just to note here, when I update or launch new branch for GameWorks these are the things I test it with:

  • I usually start with clean branch with no previously compiled binaries existing there (beyond what gets loaded by dependencies). I usually just do this brute force by wiping everything from the root folder but .git and then do hard git reset for the branch, this ensures there’s never anything else on the folder than what new users would have when they try to build this at the first time.
  • I verify that there are no additional warnings when the GenerateProjectFiles runs (some may sometimes slip through but I try to minimize them before pushing to github).
  • Then I run Setup and GenerateProjectFiles just like UE4 readme tells one to do
  • I open the generated solution using the recommended Visual Studio version by Epic, this means the default VS that the solution is prepared for by GenerateProjectFiles script.
  • I wait for intellisense/VA to process it, usually need to swap UE4 as default startup project here as I usually want to launch the editor immediately after successful build to get the shaders compiled.
  • I start building it using “Development Editor” build conf and by hitting that play button (which will launch the editor after successful build with debugger attached).
  • Once editor is fine, I open sample projects from the GameWorks tech I’ve just merged, verify it works in the editor and usually on both Shipping and Development Windows 64-bit builds. If I’m verifying an engine update instead of new GameWorks tech, I often verify that it didn’t break anything by opening random GW projects and building them, just to see there are no new issues on them.

What I don’t do:

  • I don’t test 32-bit game builds are they’ve randomly failed for me even on stock UE4 + they are not really that widely used anymore.
  • I don’t test debug editor or any other than Development Editor builds for the actual editor code (but those game packaging tests do additionally test development and shipping build confs for the actual engine code).

The things I don’t test are mainly due to time constraints, and I already do quite extensive testing on the GW feats not breaking others. For example there was a crash in some older merge I fixed that only happened with combining these techs, there Nvidia Flow and VXGI just crashed the editor when feats were used on the same scene. This and some other similar fixes are still on my latest GW merges.