Thank you for your time and effort. At stage, it would appear to me that you could make one other important contribution to the community in the form of a guide to the process of integrating Gameworks with Unreal. All that you have learned would certainly be of value to those of us, like me, who don’t have a clue as to where to start.
I also just heard from Nvidia that they’re almost done with their official porting of VXGI to 4.15 . So there’s nothing to worry about really.
I would gladly make a small video or tutorial for the process, but i’m really busy right now with big milestone coming from my game project. But i’ll keep in mind for sure.
**Edit : D’oh! I see that just replied stating that Nvidia are almost done with their 4.15 integration for VXGI, good times!
**
Just wanted to chime in with my 2 cents as I’ve been watching these VXGI threads regularly, hoping that someone will have been able to merge VXGI into 4.15 succesfully.
, I completely understand where you’re coming from. you’ve spent a good deal of time merging the VXGI code into 4.15 (glad to know it’s possible by the way, I was wondering if the new header system would break everything) and you’re not obligated to just give everyone your work at all.
I think the is that for all intents and purposes, UE4 is a free platform with an open codebase. VXGI is also free for the end-user. As a community of people all working on projects using UE4 (and some of us with VXGI), I personally feel that if Nvidia aren’t keeping their VXGI branch up-to-date and a member of the community succesfully merges all the code in themselves, releasing that code benefits many people with zero cost to that developer as they’ve already done the leg work!
In my opinion, the more of us using VXGI the better, more support threads, more useful information out there. Holding back an integration of 2 essentially free platforms feels a little hard-nosed. We all benefit!
I think the other unfortunate reality is that in months past, actively maintained his own Nvidia Gameworks merged branches, which were available for download through Github for everyone. I guess it’s just a bit frustrating to go from that to seeing that someone has achieved the same with 4.15 but doesn’t want to share (for valid reasons I do admit).
As I said earlier though, I wouldn’t feel beholden to release something I’d spent hours/days on just because people ask me to. I do understand (I think).
With all that said, I have a couple of completely unrelated questions regarding VXGI if anybody has any further info?
-
Is it recognised that VXGI and Forward Shading are incompatible? Is there a reason for ? Enabling Forward Shading in my 4.14.3 branch results in a crash on project load.
-
What are everyones thoughts on using VXGI in a VR-Based project? Obviously Nvidia have a ton of optimisations in their VRWorks branches, but as I understand it, VXGI isn’t tailored to integrate with these (perhaps resulting from the Forward Shading issues I mentioned above) as the goals (VXGI = high quality realtime indirect lighting / VRWorks = high performance VR optimisations) don’t really serve each other well.
-
Is there any information out there on whether Epic will open up the plugin system to allow something like VXGI to just be dropped into an official UE4 build without the need for a custom branch?
-
Related to the question above. Realtime GI in general in UE4! LPV is really the only option (DFGI also, but is even less developed than LPV) developed by Epic and my understanding is that it’s not being actively maintained or developed. Is there a reason for ? We’re hitting a point where most gaming PCs can happily handle realtime GI, but without a custom version of the engine using something like VXGI, it’s pretty limited. Does anyone know if Epic has a plan to iterate on LPV or otherwise build a new 1st-party solution at any point in the future?
I’m not over-dramatizing anything… Please calm down… Again I was replying to someone else, and stated that you deleted the thread, which you did.
Like I’ve now said 3+ times, I haven’t been asking you to do any more work. You’ve claimed you already have it running, pushing it to github is no real work as I haven’t asked you to support it, or extend it, or even upgrade it further, or actually even to make sure it works before you did. If you haven’t looked at my footer or read what I said on your other thread… I know all about putting large amounts of time in to both free plugins (my RMC) and free submissions to the engine or just free engine branches (RMC collision, Texture Arrays etc. ). I maintain those partly for myself and then also to help others which is how the community has gotten several great projects and also had several great additions to the engine. I’m pretty sure in one of the threads I did actually thank you for your work even though I can’t actually use it since I’m locked to 4.15. At point I’ll just wait for NVIDIA or update it myself if they haven’t released it by the time I need it.
when I click these links I get a 404 error. Has that happened to anyone else, or is there a trick to it? I have a GitHub account and I’m logged in…
You need to be linked to the Epic Games github group to be able to view the engine or its forks.
Goto… https://www.unrealengine/dashboard/settings and put your github username in the field and you should get linked to the organization pretty quick.
ugh, thanks. Apparently I didn’t accept the invitation from March 2015…the links work now!
Just to let everyone know. NVIDIA just pushed the official update so VXGI should be working on 4.15. Let them know if you find any bugs.
Iirc it’s floating around somewhere on the VXGI Q&A ‘forum’ on Github.
I just tested Flow, and I can only say… AMAZING!
BUT, I have a question, I’ve seen that it can cast shadows on itself (from directional light). My question is: Can it cast shadows from itself onto other geometry? (surrounding map). And can it cast shadows from other light types like spot lights and point lights? Can the simulation be frozen and baked to like a single frame (like : https://i.gyazo/f4b9b68e5b2984f3a3c04b05b60d09ac.mp4 (but so it can be used without simulating or playing the level))?
can you answer those questions? :)
Heres a showcase how the Smoke example looks like:
https://i.gyazo/b30e3d5d3adfb12b9dfc57246ef37d62.mp4
Smoke from geometry:
https://i.gyazo/a29ba0a1f1e9976ca0de8897c4a44285.mp4
https://i.gyazo/a6da85031ba7b2179e6eae51edf3c964.mp4
Smoke interacting with collider (I didn’t get the actual skeletal mesh to work, so I just attached a cube onto him to act as a collider):
https://i.gyazo/b9908527868803d9508eb00a95f88223.mp4
Oh also, when I have 2 Flow emmiters like shown in the last example, the bounding box seems to be smaller (?), you can see it aswell in the last example when I move the sphere up, the smoke from both emmiters just kinda stops at the top for a while and then it continues to grow again. Any fix for that?
It actually happens on 1 Flow emmiter aswell I guess (see the first link of the smoke from geometry example, it kinda stops at the top, and I’m sure that the grid is much bigger than the actual simulation.)
Can I ask if anyone has succesfully built the new Nvidia 4.15 VXGI branch?
can complete the compilation process, and the editor does work with VXGI, but packaged projects don’t work at all and just crash out instantly.
During the editor compile process in Visual Studio, and during the project packaging, I get errors like the following -
3>D:\UnrealEngine-VXGI-4.15\UnrealEngine-VXGI-4.15\Engine\Source\ThirdParty\GameWorks\VXGI\include\GFSDK_VXGI.h(1283): warning C4668: ‘CONFIGURATION_TYPE_DLL’ is not defined as a preprocessor macro, replacing with ‘0’ for ‘#if/#elif’
3>D:\UnrealEngine-VXGI-4.15\UnrealEngine-VXGI-4.15\Engine\Source\Runtime\RHI\Public\RHI.h(15): warning C4668: ‘WITH_GFSDK_SSAO’ is not defined as a preprocessor macro, replacing with ‘0’ for ‘#if/#elif’
There are tons of similiar messages, all referencing VXGI-specific code, happens on the build of the ShaderCompileWorker.
I’ve tried to build several timeson 2 machines without any modifications, same thing each time.
Any ideas? Is there something new related to the 4.15 header changes that I’m missing?
i’m building it right now and seeing the same warning messages as you.
will try it out ( also on a packaged a project ) and will give you an update later.
Cheers. For me, everything looked good, the packaging process completed (with the error messages shown above) but the executable doesn’t even load splash screen.
so i finished compiling and packaged a project of mine. worked, no crash. but i get some weird shadow mapping problems on some low poly meshes with a directional light source in stationary mode. movable and static works just fine. the mesh is a low poly door, which, when i move closer to it nearly gets black and the shadow sometimes flickers around.
edit: it seems to have nothing to do with the model being low poly. i changed it to a more subdivided model with no change.
but the material on it had tesselation enabled. when i disable tesselation, it works fine!?
anyone with the same problems?
Is the VXGI under development ? It has been 0.9 for quite some time, are there any upgrades coming in foreseeable future ?
i took some pictures of the shadowing problem i described earlier. i’m using the vxgi-4.15 branch which i compiled yesterday.
settings:
directional light: stationary
object: movable
i used the basic box shape of the engine and applied my material with tessellation enabled on to it.
i had to scale it a bit, in perfect box form it was not visible.
but it even happens on perfect boxes as the last pic will show. for the last pic i created a completely new project as i thought maybe the problem
occured due to me converting a project from base engine version to vxgi one.
box a little away, everything ok:
box moved closer to camera, artifacts showing up
box right in front of camera, almost fully black
one time i was lucky and caught the flicker effect i described:
and finally a picture of a fresh project created in vxgi version. basic box shape again with a material with tessellation on:
i hope someone can help, or if is a bug, helps finding and fixing it.
note that if i disable tessellation in the materials goes away completely.
After three days of hard work
I finally successfully merged the two branches VolumetricLighting-4.15 and NvFlowPlugin-4.15
No Github share, because my git clone is too slow, I take zip directly to merge.
Flow should be the easiest to merge in several branches, and the whole process only happens to discover the real conflict once.
Some tips on merge:
1 find somewhere to learn git and github basic skills
2 use other small projects to practice your git skills first
3 use SSD, or even ram disk to improve the merge speed
4 if git clone is slow, try zip
5 Other 4.15 compiled version After running setup.bat, the generated file seems to be able to copy directly
I has the same errors at project package. The solution I find to get ride of the errors and crashes, has to code defend the build’s. Some GameWorks dll’s and lib’s aren’t available for 32bits.
UE4 has Tools compiled has 32bits for game packaging etc.
Example: in the VXGI.Build.cs I changed.
// NVCHANGE_BEGIN: Add VXGI
using UnrealBuildTool;
public class VXGI : ModuleRules
{
public VXGI(TargetInfo Target)
{
Type = ModuleType.External;
if (Target.Platform == UnrealTargetPlatform.Win64)
{
Definitions.Add("WITH_GFSDK_VXGI=1");
}
else
{
Definitions.Add("WITH_GFSDK_VXGI=0");
}
string VXGIDir = UEBuildConfiguration.UEThirdPartySourceDirectory + "GameWorks/VXGI";
PublicIncludePaths.Add(VXGIDir + "/include");
string ArchName = "<unknown>";
string DebugSuffix = "";
if (Target.Configuration == UnrealTargetConfiguration.Debug)
DebugSuffix = "d";
if (Target.Platform == UnrealTargetPlatform.Win64)
ArchName = "x64";
/*else if (Target.Platform == UnrealTargetPlatform.Win32)
ArchName = "x86";*/
if (Target.Platform == UnrealTargetPlatform.Win64)
{
PublicLibraryPaths.Add(VXGIDir + "/lib/" + ArchName);
PublicAdditionalLibraries.Add("GFSDK_VXGI" + DebugSuffix + "_" + ArchName + ".lib");
PublicDelayLoadDLLs.Add("GFSDK_VXGI" + DebugSuffix + "_" + ArchName + ".dll");
}
}
}
// NVCHANGE_END: Add VXGI
in the WindowsPlatformMisc.cpp I changed.
// NVCHANGE_BEGIN: Add VXGI
#if WITH_GFSDK_VXGI
#include "WindowsPlatformProcess.h"
static void* VXGIDLLHandle = 0;
static int32 VXGIDLLHandleRefCount = 0;
static FCriticalSection VXGILoadCS;
void FWindowsPlatformMisc::LoadVxgiModule()
{
if (FPlatformAtomics::InterlockedIncrement(&VXGIDLLHandleRefCount) == 1)
{
VXGILoadCS.Lock();
check(VXGIDLLHandle == 0);
FString VXGIBinariesRoot = TEXT("../ThirdParty/GameWorks/VXGI/");
#if UE_BUILD_DEBUG
#if PLATFORM_64BITS
FString VXGIPath(VXGIBinariesRoot + TEXT("GFSDK_VXGId_x64.dll"));
#else
/*FString VXGIPath(VXGIBinariesRoot + TEXT("GFSDK_VXGId_x86.dll"));*/
FString VXGIPath(VXGIBinariesRoot + TEXT(""));
#endif
#else
#if PLATFORM_64BITS
FString VXGIPath(VXGIBinariesRoot + TEXT("GFSDK_VXGI_x64.dll"));
#else
/*FString VXGIPath(VXGIBinariesRoot + TEXT("GFSDK_VXGI_x86.dll"));*/
FString VXGIPath(VXGIBinariesRoot + TEXT(""));
#endif
#endif
VXGIDLLHandle = FPlatformProcess::GetDllHandle(*VXGIPath);
check(VXGIDLLHandle);
VXGILoadCS.Unlock();
}
}
void FWindowsPlatformMisc::UnloadVxgiModule()
{
if (FPlatformAtomics::InterlockedDecrement(&VXGIDLLHandleRefCount) == 0)
{
VXGILoadCS.Lock();
check(VXGIDLLHandle != 0);
FPlatformProcess::FreeDllHandle(VXGIDLLHandle);
VXGIDLLHandle = 0;
VXGILoadCS.Unlock();
}
}
#endif
// NVCHANGE_END: Add VXGI
With in advance exist more files to change, search for the implementations, and change-it to, only available for 64bits.
RHI.Build.cs
// NVCHANGE_BEGIN: Add VXGI
if ((Target.Platform == UnrealTargetPlatform.Win64) /*|| (Target.Platform == UnrealTargetPlatform.Win32)*/)
{
PublicDependencyModuleNames.Add("VXGI");
}
// NVCHANGE_END: Add VXGI
@: did you package for 32bit version of windows?
as i said my packaged game did not crash, but it was a win64 build.
@VItorEAFeliciano: after your changes, what is the expected behaviour? will it not build at all in 32bit mode, or will it skip the gameworks stuff only?
and if it skips the gameworks stuff, what is the point of using the vxgi branch then?
it seems to me that there is no solution but to stick with 64bit builds if nvidia did not provide 32bit versions of those dlls. at least for now …
please correct me if i’m wrong though.
Yes, the solution it’s to stick with 64bit’s build’s only, for Gameworks, but at 64bits build’s exists UE4 project’s (tools like automation tools, unreal header’s tools, .net projects, compiled at 32bits level) that are passing header files to known what modules to use.
Project packaging and or content cooking, it will pass headers to know what to include in packaged content.
Investigate your UE4 solution build’s to know what project’s are build at 32bits level when building UE4 engine at 64bits build.
It looks amazing but there are project’s that are only compiled at 32bit level.
The expected behaviour, it’s to not include nothing that aren’t available. Seems (shuffled), but it work.