NVIDIA GameWorks Integration

[Simon.Schirm]

Thanks for looking into this, it is essential for me to be able to add a flex particle emitter with surface to a blueprint. I have made a video of the second issue so you can see what I mean: https://www.youtube.com/watch?v=GY98p14Ycu0.

Indeed this looks like a bounds issue. The FlexFluidSurface component gets the bounds from the connected emitter instances. I haven't been able to reproduce the issue. If you haven't already, could you try to turn off the surface rendering, and re-enable the particle rendering to see whether it happens in the exact same setup otherwise?

[Simon.Schirm]

Hi


I've noticed that when you turn up the max particles inside one of the containers and run it that it goes slow (expected probably), but then turning back down the maximum doesn't fix the problem till you close the editor and re-open it. Is this a bug?

I can't reproduce this behavior unfortunately. The performance seems to recover fine for me, when reducing the max particle count in the container again. I just have to re-start playing the same map, no need to restart the editor.

[Thumbserelly]

Yeah it definately looks like tessellation is broken, I don't test very often with it on, so didn't notice until now. I dont think VXGI is to blame, Its going to take me a bit to figure out where the fault is.

EDIT: Okay fixed, as i had suspected, it was the FleX fluid vertex factory causing the issue, put in a clause to only cache if tessellation is not enabled. So I wouldn't try creating a flex fluid shader with tessellation turned on, will probably crash. Not that tessellation is support on the flex fluid surface

Hi

What line did you fix in the engine to get this working?

[Zero-Night]

Hi

What line did you fix in the engine to get this working?

https://github.com/GalaxyMan2015/Unr...4682d369f223ee

[Number47]

Indeed this looks like a bounds issue. The FlexFluidSurface component gets the bounds from the connected emitter instances. I haven't been able to reproduce the issue. If you haven't already, could you try to turn off the surface rendering, and re-enable the particle rendering to see whether it happens in the exact same setup otherwise?

I believe that the problem lies with the flex fluid surface since rendering flex particles (balls) works fine. I have noticed that when I was testing the fluid surface I was at +35286 on Z-axis in my level, and when I moved the flex fluid surface emitter to 0 on Z-axis there where no stuttering at all.

[GalaxyMan2015]

I believe that the problem lies with the flex fluid surface since rendering flex particles (balls) works fine. I have noticed that when I was testing the fluid surface I was at +35286 on Z-axis in my level, and when I moved the flex fluid surface emitter to 0 on Z-axis there where no stuttering at all.

That actually is a possibility, I have noticed that when i turn off gravity and let the fluid rise up for a while, it will turn completely black (The whole surface) based on the height of the highest piece, so maybe ur seeing something similar, but its causing it to vanish rather than just turning black. If so, then yeah not sure on the resolution.

[Simon.Schirm]

Thanks! I can repro the stuttering now and will look into it.

[ThaLobsta]

I've been experimenting with VXGI in BrickGame, and it's awesome! I have a few questions/issues though:

I have a yellowish light brick that's emissive. If I set the material to have omni directional emissive, it gets a bit brighter (not surprising), but also more saturated. Looking at the voxel emissive values in r.VXGI.DebugMode=2, the emissive color looks simply white with the omni directional emissive disabled. I can't see how that flag should affect the color, so I suspect it's a bug.

I can't increase the VXGI map size to 256 (as the PDF says I should be able to) without the VXGI library throwing an error about the texture having too many mip levels. Maybe performance wouldn't even be acceptable with a larger texture, but I'm making a painful sacrifice on nearby voxel resolution to have GI at larger distances, so I'd like to try it at least...

I couldn't find what license the integration+library is distributed under. I'd love to be able to post a binary build of BrickGame+VXGI, but AFAICT I'd have to get a license from NVIDIA first. Is that correct?

I think the VXGI support for ambient lighting could be much better with some small changes. The VXGI diffuse ambient looks like it only supports 6 directional colors, and the UE4 integration only exposes one color. It also is set up to mimic faked ambient occlusion, where the occlusion of the ambient term decreases with distance. That's a useful capability, but I'd like the option to just use the final cone occlusion to attenuate the ambient lighting. The VXGI specular ambient can use a cubemap, but it can't tint it, which I need for time of day transitions in BrickGame. It would be great if you could just give it a single cubemap+tint, and it would use it for both diffuse and specular.

Finally, I have a large radius for my sun's cascaded shadow map, and it is always rotating. VXGI seems to be using the last cascade to light the voxels, but not blurring it enough to hide the aliasing. Blurring would help, but a better tradeoff might be to get rid of the cascaded shadow map and just use cone tracing for the direct shadowing. There probably isn't enough resolution for photoreal stuff, but I think it might work well for BrickGame.

And a few screenshots..

[Mike.Skolones]

I've been experimenting with VXGI in BrickGame, and it's awesome! I have a few questions/issues though:

I have a yellowish light brick that's emissive. If I set the material to have omni directional emissive, it gets a bit brighter (not surprising), but also more saturated. Looking at the voxel emissive values in r.VXGI.DebugMode=2, the emissive color looks simply white with the omni directional emissive disabled. I can't see how that flag should affect the color, so I suspect it's a bug.

I can't increase the VXGI map size to 256 (as the PDF says I should be able to) without the VXGI library throwing an error about the texture having too many mip levels. Maybe performance wouldn't even be acceptable with a larger texture, but I'm making a painful sacrifice on nearby voxel resolution to have GI at larger distances, so I'd like to try it at least...

I couldn't find what license the integration+library is distributed under. I'd love to be able to post a binary build of BrickGame+VXGI, but AFAICT I'd have to get a license from NVIDIA first. Is that correct?

I think the VXGI support for ambient lighting could be much better with some small changes. The VXGI diffuse ambient looks like it only supports 6 directional colors, and the UE4 integration only exposes one color. It also is set up to mimic faked ambient occlusion, where the occlusion of the ambient term decreases with distance. That's a useful capability, but I'd like the option to just use the final cone occlusion to attenuate the ambient lighting. The VXGI specular ambient can use a cubemap, but it can't tint it, which I need for time of day transitions in BrickGame. It would be great if you could just give it a single cubemap+tint, and it would use it for both diffuse and specular.

Finally, I have a large radius for my sun's cascaded shadow map, and it is always rotating. VXGI seems to be using the last cascade to light the voxels, but not blurring it enough to hide the aliasing. Blurring would help, but a better tradeoff might be to get rid of the cascaded shadow map and just use cone tracing for the direct shadowing. There probably isn't enough resolution for photoreal stuff, but I think it might work well for BrickGame.

And a few screenshots..

Hi Andrew,

I'll bring your post to the attention of the VXGI team, I don't have an answer to your question about the map size, or the bug.

Regarding the license, you are covered by the UE4 End User License Agreement. By submitting the code into the UE4 code base on a fork owned by Epic, we are following the terms of the EULA on our side, and you are entitled to use it like any other feature in UE4. Of course, NV would _love_ to get an advance peek at your game, etc. Feel free to send me a private message if you want to discuss the business side of things in more detail.

--Mike

[Gandosh]

Is VXGI emissive material capable of casting shadows? I'm seeing very awesome light coming from my emmisive material. But i dont see the shadows. Is it just me or VXGI does not cast shadows from emissive material?

[Mike.Skolones]

It should cast shadows from emissive materials. What other lights are in your scene? Do you have a screenshot?

[Gandosh]

Nevermind its casting shadows. I was expecting sharp shadows xD. By the way What is this pixelated, boxed kind of things on speculars? I have this all over my scene, if its moving object its really noticeable. What value should i increase?
and is there any chance we getting NVidia Antialiasing stuff?

[Mike.Skolones]

Nevermind its casting shadows. I was expecting sharp shadows xD. By the way What is this pixelated, boxed kind of things on speculars? I have this all over my scene, if its moving object its really noticeable. What value should i increase?
and is there any chance we getting NVidia Antialiasing stuff?
[ATTACH=CONFIG]43376[/ATTACH]

Specular reflection is one of the weaker aspects of VXGI currently, and we are working to improve it, but the performance is expensive and it will not look as sharp as a cubemap reflection anytime soon. We'll post some advice about parameter tuning ASAP, I don't know offhand what is causing this artifact, but I would think that the cone sharpness is a factor.

I'll see what I can find out about a schedule for TXAA integration. We have a new version, TXAA-3, coming out soon.

--Mike

[Gandosh]

Thank you very much!

[Alexey.Panteleev]

I've been experimenting with VXGI in BrickGame, and it's awesome! I have a few questions/issues though:

I have a yellowish light brick that's emissive. If I set the material to have omni directional emissive, it gets a bit brighter (not surprising), but also more saturated. Looking at the voxel emissive values in r.VXGI.DebugMode=2, the emissive color looks simply white with the omni directional emissive disabled. I can't see how that flag should affect the color, so I suspect it's a bug.

I can't increase the VXGI map size to 256 (as the PDF says I should be able to) without the VXGI library throwing an error about the texture having too many mip levels. Maybe performance wouldn't even be acceptable with a larger texture, but I'm making a painful sacrifice on nearby voxel resolution to have GI at larger distances, so I'd like to try it at least...

I couldn't find what license the integration+library is distributed under. I'd love to be able to post a binary build of BrickGame+VXGI, but AFAICT I'd have to get a license from NVIDIA first. Is that correct?

I think the VXGI support for ambient lighting could be much better with some small changes. The VXGI diffuse ambient looks like it only supports 6 directional colors, and the UE4 integration only exposes one color. It also is set up to mimic faked ambient occlusion, where the occlusion of the ambient term decreases with distance. That's a useful capability, but I'd like the option to just use the final cone occlusion to attenuate the ambient lighting. The VXGI specular ambient can use a cubemap, but it can't tint it, which I need for time of day transitions in BrickGame. It would be great if you could just give it a single cubemap+tint, and it would use it for both diffuse and specular.

Finally, I have a large radius for my sun's cascaded shadow map, and it is always rotating. VXGI seems to be using the last cascade to light the voxels, but not blurring it enough to hide the aliasing. Blurring would help, but a better tradeoff might be to get rid of the cascaded shadow map and just use cone tracing for the direct shadowing. There probably isn't enough resolution for photoreal stuff, but I think it might work well for BrickGame.

And a few screenshots..

The emissive voxels going white most likely means VXGI is using UNORM8 emittance, i.e. non-HDR, and it gets saturated when it gets brighter. To get best results, we recommend to set bVxgiStoreEmittanceInHdrFormat=true in BaseEngine.ini. This option changes the emittance format to FP16 (on Maxwell) or FP32 (on other GPUs). You can also experiment with VxgiEmittanceStorageScale option (same location) and see if there's a setting that looks good with non-HDR in your case.

The error with map size = 256 is a bug in the config validation code; it's already fixed in the development version, and the fixed DLL should be out with the next release. Performance with such a large map is really poor though.

We certainly can add a tint for the cubemap, and cubemap support for diffuse ambient lighting. I'm not so sure that the ambient term multiplied by final opacity will look well, though, but it's
easy enough to try.

We also had the idea of using cone tracing instead of shadow maps, and there was an experimental version like that. It was much slower than shadow maps, and the quality was much worse. So I guess we'll need to improve cascaded shadow map sampling during voxelization.