Then I keep trying. VS2015 may be having problems. Thanks for the info.
thanks for the quick reply. I just tried your latest build and the issues are gone, no more red light and no more crashes. Is there anyway I can use VXGI in this build with my 780, since r.VXGI.AmbientOcclusionMode= 0 means no VXGI and my GPU doesn’t support r.VXGI.AmbientOcclusionMode= 1?
r.VXGI.AmbientOcclusionMode= 1 means you can only use VXAmbientOcclusion.
r.VXGI.AmbientOcclusionMode= 0 means you can use Full VXGI+AmbientOcclusion.
@Alexey.Panteleev I have just tested the updated branch. I noticed VXGI voxelization and tracing frame times are good but when I enabled VXGI (Only Directional Light) with optimized parameters, my fps drops 97 to 48 on GTX 980Ti because of shadow depths. Is It usual or there is another problem? I uploaded GPU profiler results. First: Shadows and VXGI enabled (GI only). Second: Shadows enabled but not XVGI. Third: Shadows and VXGI disabled. Fourth: Shadows disabled VXGI enabled (GI only). Also, I noticed that in fourth scenario GPU visualizer shows 3 ms less than viewport values. Is this “half of the fps” situation nature of VXGI? I thought that VXGI 2.0 would be much faster than old one, up to 2x according to updates. But fps which I had drop doesn’t verify this is true.
@0lento - I’ve managed to package project using your branch.
In this case, a large part of the fps drop comes from shadow map rendering, the ShadowDepths pass. Like I mentioned, when VXGI is enabled, the directional light shadows include all objects that are covered by the shadow map, not just those affecting the current camera view. You can see that using “vis ShadowDepthAtlas” or “vis WholeSceneShadowmap” and toggling VXGI on and off. It’s probably possible to do some culling still, or limit the range of cascades that are used for VXGI. Since you observe such a significant slowdown, it would be great if you could send me the scene, or something else that reproduces the same kind of slowdown, and then I can try to optimize the code (or settings).
VXGI 2.0 is generally faster than 1.0, but no one said you will see 2x speedup overall. In the GDC presentation, I mentioned that voxelization can be almost twice as fast in some cases, mostly because it can be done in a single pass now. Other things like voxel processing and tracing have been somewhat improved. But not shadow map rendering, as that’s part of the engine, not VXGI. (Actually, it’s probably possible to implement single-pass directional shadow map rendering using Maxwell-2 FastGS, which should give a speedup for everyone using UE).
Hey, I’m kinda curious since you specify ‘HBAO+ / HBAO+ 4’ for some of the builds.
It’s a bit confusing since there’s already a feature in the VXGI builds that’s called hbao.
I’m assuming what’s in the VXGI builds is actually the Voxel AO / VXAO.
While when you specify HBAO+, it’s the screen-space HBAO from a separate branch?
( aka the one from here NVIDIA ShadowWorks | NVIDIA Developer , but without shadowworks itself, which doesn’t seem to have any kind of UE4 implementation yet. )
VXAO and HBAO+ are in fact two different bits. HBAO+ also is in VXGI builds by default, just not sure if it’s HBAO+4. Maxime, 0lento or Alexey would know better on the differences there. And ShadowWorks is something totally different from the ambient occlusion stuff.
What would that process look like? Is that something simple to do?
Not sure if this is easily fixed but making a typo when entering a voxelsize in the console (example ~32 as opposed to 32) will crash the editor.
It’s HBAO+ from VXGI2 branch. I specify it separately as it’s a separate GameWorks tech from Nvidia, it’s not coupled with VXGI technically in any way, they just chose to distribute them at same merged branch.
Meaning, you can technically strip out all VXGI code from the nvidia VXGI branch and have only HBAO+ left and it still works (we’ve done that for UE4.15 when I didn’t need VXGI for anything).
thank you for this important information. If there is a way to have a more optimized VXGI I will do whatever I can. If you send me an email or something like that I can send a scene to reproduce. And also dynamic shadow cost is a big deal in Unreal for open world. If its performance will be improved too, with VXGI, Unreal would be a better position for open world to compare with CryEngine.
Hey, what’s up UE4 community. I’ve returned to Unreal Engine after being away for 2 years. I was one of the early developers who kept begging Epic to implement a dynamic GI solution after SVOGI got canned. Things looked grim for me until I came across VXGI and started following it. Now after seeing the cool new results being achieved with 2.0, now feels like the time to return back to UE4!
Hey dude, I want to thank you for your work on VXGI. It reinvigorated my interest in real time rendering again and it’s cool to see you’re on the forums. I was wondering, with the latest Ray tracing announcements from Nvidia and Microsoft, what will the future of VXGI look like? Will it continue to be its own thing or will it eventually merge with those new technologies?
Yes, HBAO+ 4 is integrated in the VXGI branch.
ShadowWorks is a marketing name for the collection of HBAO+, PCSS and HFTS: NVIDIA ShadowWorks | NVIDIA Developer
UE4 has a PCSS feature of its own, but HFTS is not integrated, as far as I know.
Implementing single-pass cascaded shadow maps is not exactly simple. Overall, it would replace the regular CSM rendering passes with one coarsest cascade, and use multiple viewports to represent all the cascades at once. The new pass will use a FastGS shader to multicast each triangle into a number of those viewports, depending on which cascades it intersects with. There may be complications though: if shadow maps are too large, the DX limit on viewport size (+/- 16k pixels) can become a limiter, in which case it will be two passes instead of one. There also may be some accuracy issues.
We have a sample that does this (in GL): https://github.com/NVIDIAGameWorks/GraphicsSamples/tree/master/samples/gl4-maxwell/CascadedShadowMapping
This was fixed yesterday. I added some validation/clamping on the important cvars. Turns out ~32 translates to just 0.
Yes, VXGI is playing in the same field as the ray tracing tech, sort of. And it doesn’t give the same level of image quality. But VXGI is much faster than ray tracing, if you implement similar effects using both. There are some possible paths for them to converge, like using RT for mirror reflections and VXGI for everything else, or using RT for contact shadows. We’ll look into that.
I made a performance experiment with VXGI for open world. (with performance tweaks such as map size X, Y, Z 64) And the results on GTX 980Ti & i7 5930K.
4x4 level with average tree density.
ATTENTION! AFTER THE UPDATE DIRECTIONAL LIGHT VXGI PERFORMANCE HAS BEEN FIXED. FPS INCREASED TO 80 FROM 48.5.
importing FBX takes crazy long. is that VXGI build spesific bug or 4.19 related?
I haven’t personally noticed that issue. Larger FBX files, of course, take longer to import. Or if there are issues with the mesh.
yea looks like im doing something wrong when exporting fbx from houdini
I finally got VXGI 2.0 installed on my computer and I have to say, I’m having a blast with this! As someone who does a lot of offline rendering, real time G.I is the future. I’m finding it incredibly hard to go back to the likes of Vray and Mental Ray after using this. Instant feedback is so much more satisfying than waiting for an image to render.
Best of all, I’m doing this all on a GTX 960. A $200 card from from 3 years is doing GIobal Illumination at 30 to 60 frames a second!
I posted more of my work here.
Hi, any news ETA on flex for 4.19?
There are a couple branches now that have it. Mentioned in this thread.