@kostenickj what is the bug with GPU skinning that your other commit fixed? Also can you tell the purpose of that usf inclusion I linked last (in case I missed something).
Anyway, I’ll build 4.20-GameWorks now myself and see if I can repro the.
Wow, he looks great. We’ve been waiting for a long time.
Now everything looks great. It looks like we just need VXGI to get the full 4.20 version of the Gameworks engine.
What I want to say is that VXGI is being used by a lot of people, because the illusion engine is now far from being used in games, and the visual enhancements VXGI brings to other areas are very important, so we all attach great importance to VXGI, and even more than anything else in the Gameworks.
Thank you for bringing us another 4.20 version of Gameworks. We are very much looking forward to it.
Thanks a lot!! I did look at your repos before but must have overlooked it. Do you know if VXGI would work with multiple GPUs? I’d like to run it in VR on a small interior scene, but from some quick tests 1080Ti is not enough
It is enough, VXGI is very scalable. You’ll just need to invest some time to figure out what and how affects performance. I doubt SLI will work efficiently in VR without VRWorks.
I must add that it is very important that it is as realistic as possible. Do you know any resources on the internet how to optimize it? Is there someone who merged VXGI and VRWorks?
It all depends on you how good the result will be in the end and how well you will trade off quality for performance. There seems to be no “ideal” settings, every scene is different and requires a slightly different approach.
There is not much really, there are like 2 PDF files with recommended settings without getting into much of a detail. There are also in-engine tooltips which is the main source of info. Some of the commands were changed or completely removed for VXGI 2 so be aware of that as well. In the end it all comes to just a lot of testing and reading forums including branch.
Yeah, I would not at all be surprised if VXGI becomes obsolete pretty quickly once RTX stuff is out and available.
( Especially considering the stuff they showed off spring : watch?v=tjf-1BxpR9c )
Though the multiple delays of the RTX cards, alongside with the unknown delivery time of RTX makes me wonder for when that’ll actually be.
I do look forwards to the time when it’s out and usable for us. (But I still wish they’d atleast bump VXGI2 up to 4.20 so that it can be used alongside the upgraded cinematic DoF there. Especially since it seems like 4.21 is far off, though they’re still targeting a release year. )
Yes, RTX will take the place of VXGI, but RTX seems to take at least six months to officially launch and mature, and during time we still need VXGI to provide the closest real-time picture to ray-tracing, and now it seems that only VXGI can meet the demand for ray-tracing-level images.
But NVIDIA seems to be putting all its energy into RTX, and VXGI seems to have no one to manage the updates, which is a big headache. It has caused us to be unable to replace 4.20, or even 4.21 engines, because VXGI has always been very important to us.
If VXGI is truly essential for your workflow, I’d suggest learning how to port it from engine version to another yourself. It’s not an impossible job, but it can be tedious. Porting VXGI from 4.19 to 4.20 will realistically take few days if you know what you are doing and can take up to a week or more if you haven’t done kind of work before (knowing how to use git is essential skill ). I’ve already ported the HBAO+ part of 4.19 VXGI branch for 4.20 so one could just apply my HBAO+ fixes to speed up the process. The reason I haven’t done it myself is that I have no motivation to do it, it’s not trivial few hour port as some of these techs are and I don’t need it for anything. My own time is limited so I have pick what I can do with it.
Since it’s realistic to asume that there’s no official VXGI for 4.20 from NVIDIA coming soon - if at all, I’ve reconsidered waiting for it and will go on with porting VXGI for 4.20 in my fork. Can’t say when it will be finished though, since I’ve just started working with UE code. I’ll post news on progress . Some guiding hand from some veteran would certainly help speed up the process and be much appreciated. https://github/HaBe2305/UnrealEngine-GameWorks/tree/4.20-VXGI2
1 : About BLAST, I don’t know how/where to set if a chunk must block an actor like my character, depending on the size of the chunk. By default the non destroyed parts of the mesh are blocking me, but as soon as they are broken (even if they moved from 1cm), I can pass through them.
2 : Why is NVidia integrating all these Gameworks in different forks, instead of making one fork containing all Gameworks? A big studio have the ressources to modify the engine itself to use the Gameworks it needs, but for indy devs it’s more difficult…
3 : Do you know why Epic Games don’t add some of these Gameworks to the official engine? I’m thinking about BLAST that is ways better than APEX, FLEX because there is no fluid simulation, soft body simulations and physical ropes simulations… (About the rope simulation, Flex is not needed, but with Flex it’s ways easier and less bugged than the ones I saw on internet made from scratch with the official UE4)
these specific Gameworks are not optionnal graphic tools, they are useful to build innovant gameplay!
I’m not a programmer, so I haven’t thought about learning to transplant myself, but I’ll try it from now on.
Thank you so much for bringing us all kinds of Gameworks ports, and I’ll gradually start to learn how to do that until one day I can do some of the work myself.
I’m sure some nvidia staff member has answered in past already but I can think of multiple reasons:
Nvidia tech integrations for ue4 are maintained by different people, putting them all together would force them to solve a lot more conflicts (I imagine combining things like VRWorks and VXGI and fixing all the related issues from version to another would consume way more manhours than their current approach).
People who use the engine for serious projects usually don’t want anything extra that can potentially cause issues + it can bloat the final distribution size if the compilation switches are not setup properly. for example, I personally wouldn’t ship a game on my GameWorks merge branches if the game only requires Flex and Flow. These merges are great for testing different techs tho but very few games can actually use all of them at once.
Upgrading the nvidia techs from one engine version to another would be really painful for them as the work couldn’t be done by only people who know the specific part of the tech (you get tons of merge conflicts even for one tech, then imagine same for 10 etc at once). To work efficiently , you’d always need to have the separate branches per tech anyway for reason alone.
And finally, there’s always been some community members who do these merges eventually, so they fill the gap between what paid teams and smaller devs can do with these.
If Nvidia only shipped these as one big merged branch, it would be pretty painful to get the individual techs out. They’ve currently merged HBAO+ and VXGI and I’ve separeted HBAO and VXGI twice from nvidias branches, it’s doable but it’s really time consuming and it only get harder the more techs are involved as it’s a really manual process. In the end, if these were merged together, the compilation switches would really need to be robust (I know at least FleX has some issues with them, hence overriding the def on some repos).