What’s New in Version 2.0
- VXAL, or Voxel Area Lighting
- Improved overall performance
- One-pass voxelization
- Simpler controls for tracing and voxelization
- Support for custom G-buffer layouts
- Stereo view reprojection
- Simultaneous VXGI and VXAO
Well, VXGI 2.0 actually requires a GPU with certain post-.0 features to be completely functional. There is no plan to make it compatible with older GPUs again. But you can still use VXAO/AL on Kepler, for example.
It shouldn’t crash though, I admit. That is to be improved.
@.Pateleev
Thank you for your devoted work. Is it possible to use VXGI 1.0 on UE4.19? I think it was a very sudden end to VXGI 1.0.
Thanks for your efforts on keeping VXGI alive! In my limited testing it’s a major improvement. A few issues so far with the NVIDIA 4.19.1 build…
I’m assuming it isn’t compatible with Forward Shading? Every time I try to open a level with Forward Shading enabled it crashes the editor.
I can get it working in VR (using Deferred Shading) but performance on a simple scene is still less than optimal. Any VR settings recommendations would be great to hear about.
On that note, have you thought about putting together 1-3 sample scenes representing simple yet optimal setups? It might alleviate many of the questions about best practices.
LOL why would you use an inferior version
-
Simultaneous VXGI and VXAO
OH MY! OH MY! someone. merge vxgi and hairworks together please :p:p:eek::eek:
I believe someone else already has!
There are two third party repos on thread already that do that ;D
Why would you use 1.0 when 2.0 is available? It’s so much better.
Because I want more people to play my game. If the VXGI 2.0 also works on Kepler graphics cards, that would be very nice.
VXGI 1.0 is unusable for games. Way too ressource intensive compared to 2.0. If you want more people to be able to play your game you should use 2.0, it’s twice as fast as 1.0. And even 2.0 can be quite intensive even with a good rig.
Is VolumetricLighting discontinued? I see it stuck on 4.17.
@ thank you so much for all your contribution to the graphics rendering field!
I have tried using Blast and performance is the major. The problem is not with Blast’s performance itself but with the fact that Blast, by design, only generates the destruction and relies on the UE4 CPU engine which doesn’t scale well with the amount of rigid bodies Blast generates. Therefore, do you think it would be possible to integrate GPU Rigid Body to UE4 to improve Blast’s performance?
Also, it is a real shame that VRWorks Audio was integrated in 4.15 which was the last version before the new Unreal Audio Engine therefore it has bite the dust since 
hopefully it will get upgrade and come back to life someday.
windy has a .18 build with all the bells and whistles inc vxgi and volumetric lighting
https://github/windystrife/UnrealEngine/tree/4.18-NVIDIA.GameWorks
who the hell still using Kepler anyway o_O
As I saw in Nvidia sources, VXGI was designed for GPUs at the beginning. VXGI 1.0 was extremely expensive. Even the best GPU had not enough power to use it in a complete game. So there is no way to use VXGI with old and slow Kepler Cards.
Volumetric Lighting works with minor changes on 4.18 and 4.19. I have it running on 4.19 atm as well but still need to fix few profiler macros, I might push it into my 4.19 GW merged branch eventually. My 4.18 port of Volumetric Lighting is included in (which includes UE 4.18.3, Blast, Flex, Flow, HBAO+3, VGXI1 and Volumetric Lighting).
My 4.19 Gameworks merge () currently has UE 4.19.1, Blast, Flow, Hairworks 1.4, HBAO+4, TXAA3 and VXGI2 and includes latest fixes from nvidia and one crash fix from me for Flow.
As additional note, I try to keep all my GameWorks commits clearly separate for individual techs if the change is beyond fixing something less important, like UBT warnings. I also prefer keeping each initial merge squashed into single commit. There are few core reasons why I prefer approach:
-
it’s easier to upgrade specific individual tech for the next UE4 version as you have all needed things as separate commits with clear indication on what is from original merge and what was changed to make it compatible in case it was ported from earlier engine version. Nvidia usually does it like .
-
you can cherry-pick individual techs and fixes easily if you don’t want to merge all techs, you only need to have same major engine version (like 4.19.x) and it should be trivial to cherry-pick things without that many conflicts. Had these been in one big commit, it would be way harder for me to separate what was needed to change.
-
when the original tech branch merge is squashed into single commit, you can easily examine everything that individual tech/commit includes (through github, gitk, or your preferred git client) as it’s not yet mixed with other commits. Of course once there are bugfixes or changes after the merge has been done, those will have to be done in separate commits, so what I said only applies for the initial tech merge for the next major engine version.
There are not as many + users as you might think.
https://store.steampowered/hwsurvey/videocard/
I mean it would be nice if VXGI2.0 would also work on Kepler architecture.
We will look at what we can do in state. Thanks for your advice.
@SilentAndAsleep @alperenozgur
My quick math did tell that on that hw survey, 68,73% of current steam users has or Pascal (including first generation Maxwells). But that is irrelevant since even many of those maxwells are not powerful enough to run VXGI properly anyway.
