Ah, I didn’t mean you specifically, I should have worded myself better, my bad. When you wrote “us” on your previous comment I assumed you meant you work in some team and game teams tend to have programmers unless it’s some pure arch viz thing. My answer was generalizing with term “you”, I should have used “one” but I’m not a native English speaker so I make small mistakes and there. You’d need at least basic level of c++ and git skills to be able to do task like (which is pretty common for a programmer but can take REALLY long time for people who has never done anything like that).
**Update: **After consolidating NVIDIA’s low level headers from the different integrations, it turned out pretty straightforward to port VXGI2 to 4.20.
It compiles fine on my system, but it turned out that my NVIDIA board is too old. Since I can’t afford a recent NVIDIA card (.3 level / ), I can’t test it myself. So testing and pull requests by others are more than welcome. Until then branch will be experimental and stay seperate from the main branch:
It seems like I need more time to figure out how to migrate, but thank you very much for bringing us the perfect version of the Gameworks. We’ve been using your 4.19 Gameworks version for a long time. It’s very stable. Thank you for your efforts.
Hello, I had a problem testing your VXGI version. The main problem was that the material system didn’t seem to display properly. All the materials were gray after compiling the shader, but you can see the normal material and texture when you open the material. At the same time, VXGI seems to have failed to take effect? I didn’t see any effect when I used it in post-processing. All the options and commands associated with VXGI didn’t seem to work and voxels didn’t exist, but VXGI still consumed performance.
These two problems are the main ones we are encountering now. The rest are still under test. Thank you for VXGI version 4.20. I believe it will be better!
Thanks for trying it out. I’ll have another look into the code, maybe I can find something related to the problems you describe on the code side without actually running the editor. If you manage to find out more or even find a fix, please feel free to commend further or make a pull request.
I also found that when all the materials were opened, there was a strong GI effect around the material display view, which seemed to be brought about by VXGI. The current situation is that the normal viewport can not display the material, but it seems that the first time I compiled into the engine, you can see the material is normal display. But when the material is displayed normally, the engine compiles shaders again. After compiling, I can’t display the material normally in the viewport of any project. Only when the material is turned on can you see the material with the texture and shader, and a strong GI effect around the material.
At the same time, VXGI also can not work properly, post-processing and any command of the console can not display VXGI normally in the viewport, but there is a strong GI overflow in the material preview window.
But I am not a programmer, so I can not find a solution, I can only help you to test engine.
In addition, the hardware I use is I7 8700K and GTX 1080Ti, in previous versions can normally run the Gameworks plug-in.
[quote=“, post:5065, topic:16686”]
https://github/HaBe2305/UnrealEngine-GameWorks/tree/4.20-VXGI2
hi we build it no texture or material work only black and white why???
As stated further up already, is still experimental and needs further testing - and now also fixing apprently - from someone from the community who’s a coder and has a recent NVIDIA board. I’ll do the best I can to find out what is causing , but without a recent NVIDIA board, I’m currently limited to looking at plain code. Since I did the time consuming part of porting and merging already, it should be comparably straightforward for someone with some engine experience and capable hardware to fix it. Until someone like that pops up and does it - or I find a way to get a recent board somehow, you should consider VXGI port not ready for anything yet. Sorry for that.
if trying to fix things like , one should still make a the merge manually to see the possible initial conflict (in case files have moved around) as that’s not visible from the merge commit itself. Others work helps but if it’s not functional, it’s pretty hard to start guessing why some changes were made.
I’ve actually done most of these GameWorks changes myself when I first tried merging it but decided to postpone it back then as I didn’t know how to fix certain changes without digging deeper into UE4 side changes. I did take a look at your changes at (commit was bit hidden but I found it) and for example your fix removed bunch of things that I originally changed to go with the new API.
I don’t remember that well anymore what was the point where I stopped working fixing my own VXGI merget but I have a faint idea what were the showstoppers. I don’t really have much time to put into atm but will see if I could give some pointers on things that might be off.
Thanks @, really appreciated. I just found out what the problem is (mostly has to do with a bad auto merge, and partly my fault) and I’m currently going through your whole 4.19 version and comparing and porting it to my 4.20 branch again, time completely manually. After looking into it again, I also remember now where I stopped porting it. The hardest part is in the SceneRenderTargets code, because Epic changed the shader parameter handling to a uniform buffer architecture, so it takes a bit more porting on that part. But I’m already halfway through and I’m confident (at the momnent at least) that I’ll be able to pull it through with some help.
I’ll post again when I’m finished (or can’t get further) and the commit is up, so you guys can test it and see what is happening then. I’m sure that we’ll make it happen if we all work together on , it’s just a bit unorthodox way and a bit more time consuming because it needs more iterations than usual (if I could see what my changes actually do in the editor).
Thank you very much for your work.
Hello,
Does VXGI 2 currently support Skylight bounce/occlusion?
VXGI 2 supports the rebound and occlusion of daylight, but it doesn’t seem obvious. By default, daylight in VXGI 2 has the option of VXGI computing enabled.
Thank you, finally I can have VXGI in 4.20! I can see you have Waveworks in a different branch, is it because of some conflicts that you separate it or it should be fine to merge them? Cheers!
@ is there a reason that the ios sdk isn’t included in the build?
Right now, it’s in a different branch because I’m still in the process of sorting things out for a successful port to 4.20 and then in a second step to merge it into the main branch of my fork. I’ve posted about it already in hopes of getting some help, mainly because I’m not able to see what my port actually does due to not having a NVIDIA board that is recent enough to support full VXGI. So it will take some time and a couple of iterations until it’s ready - that is, unless there’s a show stopper that we don’t have discovered yet. So my suggestion would be to keep your horses calm for now. 
@ Small question just to be sure: Do you remember doing any changes to your 4.19 branch besides the code NVIDIA added/changed to make it work, that are NOT marked by some form of comment? Because right now I’m only looking for diffs that clearly have todo with VXGI and I start to suspect that I missed something essential outside of that.
Sorry, read it again and noticed you were talking about WaveWorks in the second part :rolleyes:. I’m still in the process of porting it, it’s not ready yet. I’ll post as soon as it’s done or there’s a show stopper that I can’t get around. My main goal is to have mostly all GameWorks tech in one build for Cinematic work that I plan on doing, and on the long run to make it easily configurable what GameWorks tech will be included in the final build of the engine without having to do these merges over and over again. But there has quite some work to be done yet until that is going to happen.
So I have been using the VR Acoustic Ray Tracing
https://github/EpicGames/UnrealEngine/compare/release...NvPhysX:VRWorks-Audio-4.15.1
And coming across a few issues when trying to merge it with more recent versions. Any help would be appreciated, as we are attempting to implement VoiceCapture into the Acoustic Ray Tracing and are coming across runtime errors that supposedly have been resolved by version 4.17.
Any help would be greatly appreciated and will share the code of the project
github/mrg7/myproject
is my case too. I’m doing animated series in UE4 and have the luxury of not worrying about real-time performance. I’m having 4.19 with NVidia,TrueSky and a couple other techs and would love to have those upgraded to 4.20 to enjoy the new engine features. Can’t wait for your build, cheers!