NVIDIA GameWorks Integration

[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 pixelated, boxed kind of things on speculars? I have all over my scene, if its moving object its really noticeable. What value should i increase?
and is there any we getting NVidia Antialiasing stuff?

[Mike.Skolones]

@;309933

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

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 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.

–

[Gandosh]

Thank you very much!

[anonymous_user_7c71c8ec]

@AndrewJSch;309838

I’ve been experimenting with VXGI in BrickGame, and it’s ! 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. option changes the emittance format to FP16 (on ) 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.

[anonymous_user_7c71c8ec]

@;309933

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

Not sure why it’s pixelated, usually when specular looks bad it’s either voxels or banding or screen space aliasing. Can you try changing the Specular Filtering setting and material roughness?

[ThaLobsta]

@.;309856

Hi ,

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 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.

–

Great, thanks! is just for fun, but 's a build: ://www.scheidecker.net/BrickGame-VXGI-2015-06-12-17.00.rar

@;310002

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. option changes the emittance format to FP16 (on ) 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.

I actually increased VxgiEmittanceStorageScale already to fix the brightness, and didn’t notice it fixed the saturation as well. Sorry, my mistake! FP16/FP32 is way overkill for me.

@;310002

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.

That’s what I did in SVOGI, and it worked well. Shadowed sky lights for free! Though to be clear I multiplied the total transmission of the cone by the ambient lighting.

@;310002

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.

I’m sure it wouldn’t be as sharp, but that’s fine for my purposes. I would actually be happy with softer directional light shadows. Have you considered creating a signed distance field from the voxels and using that to skip samples for the the narrow cone traces? Apparently Tomorrow’s Children does that to accelerate tracing reflection cones, but I imagine it would help shadow traces just as well.

Thanks for your help!

[Nudlegaru]

@ @ Greetings. No answer about the VXGI problems in colour bleeding and mixing in my comment from the last page?

[Mike.Skolones]

@;310154

@ @ Greetings. No answer about the VXGI problems in colour bleeding and mixing in my comment from the last page?

Sorry, I must have missed that. I’ll take a look at the videos.

[Zero-Night]

With the ability to add plugins to the marketplace, do you have any plans on adding the Gameworks files to that? Could make integrating things a lot easier for a lot of people, and lead to more widespread adoption.

“only the source required for integrating with the engine, so we can work with it ourselves and test it properly. Everything else can remain closed source. We have full respect for code plugin developers wanting to keep their secret sauce secret”
https://forums.unrealengine/showthread.php?72760-Plugins-now-accepted-What-do-you-need&p=309958&viewfull=1#post309958

Seems like it would be a good fit, assuming it’s possible to integrate it through however they’re doing it.

[anonymous_user_bcf66e2c]

Problem isn’t the propriety code, its the actual integration, they are heavily integrated into the renderer, at point in time, there would be no way to convert them into plugins. Unless Epic can expose more of the renderer, such as the main render pass, and such to plugins, it will have to remain as a separate integration.

[Zero-Night]

Is there a reason why Epic wouldn’t want to do that? I was under the impression they were trying to allow users to modify the engine however they need, hence the available source code. Is it just a matter of them not getting around to it yet? (assuming it’s even possible)

I would imagine it would only be to their benefit to implement it, not only for plugins like VXGI but for what else people may come up with to extend the engine.

[Mikand79]

Of course its possible. They would need to refactor stuff and place plugin-usable anchor points into stuff. Some guy on the Forum changed parts of the rendering code (or the shaders?) to be extendable by plugins already. I think Epic didn’t do it yet because its the core system and they try to develop one or more commercial games on their own with it already too, seems risky (and laborous) to rearchitecture it now.

[Zero-Night]

Yeah. It would take a lot of time, I’m just thinking of things like TrueSKY, VXGI, AHR, or whatever comes along next. It’s difficult for the average user (or artist without programming knowledge) to integrate multiple plugins themselves without breaking things, and it gets harder to maintain as you start adding more from various sources and branches. Just seems like the logical progression to add when there’s already a marketplace that’s capable of handling all of that.

Of course, I say all from the point of view of someone that wouldn’t know the kind of work that would need to go into that. As useful as it would be, it might not be worth the months of effort that it sounds like it might take.

[anonymous_user_bcf66e2c]

I agree that would be something beneficial to the plugin approach, hell, it would mean I could release some of my stuff as plugins instead of trying to find workaround and I really do hope that Epic take the time to implement more and more functionality overrides into plugins. Right now the ball is in Epics court, or an individual who is willing to put in the effort, much like Temerran (Hope I spelt that right, I apologise otherwise) did for the project dependent shaders.

[Gandosh]

Ok that pixelated, grid thing on speculars was caused by VXGI Specular Tracing Filter. It was turned on by default. When i turned off it goes away. But it gives me pretty bad result until i set my Spec Tracing Step to 0.5.

[anonymous_user_7c71c8ec]

@ @ Greetings. I know that VXGI still has problems with smooth reflections but I wanted to notify you about :

On the Ball , the reflections of the mannequin is flickering even when he deosn’t move. I can also see many voxels of the the edged of the reflected emissive balls. and from certain angles I see voxels in circles inside the reflected balls: ://imgur/a/jKonA

But what bothers me the most is that the Colour bleeding and mixing don’t work in most of the cases. I expected to get results like these : ://www.enchantedlearning/crafts/Colormixing.shtml

Well only red + green and and very little blue + green worked a tiny bit. The others didin’t work at all. I was expecting to get green on the wall after the colours mix : ://i.imgur/N8OYlJO.png?1 etc

Well few months ago, I used LPV and it gave me great results in colour bleeding and mixing and that chnaged even using time of day and from where the sun was facing the walls : ://imgur/a/VGQnS

Effectively colours do mix and the results are like : ://upload.wikimedia.org/wikipedia/commons/2/2c/Additive_color_mixing_simulated.png

is a video : watch?v=ksS-FJ3B8Og

I really hope VXGI will get to that level and we can see such colour bleeding and mixing. Thanks.

Color mixing should work fine, all the math in VXGI is additive in RGB space - and that is physically correct. Unless some saturation in the emittance map is involved, that is.

The page that you reference talks about color mixing in a different color space, like paint on paper. In RGB space, blue (0000ff) + yellow (ffff00) is white (ffffff) - and that’s what you get on that picture, multiplied by some small factor that makes output gray.

RGB color model

[Nudlegaru]

@;310686

Color mixing should work fine, all the math in VXGI is additive in RGB space - and that is physically correct. Unless some saturation in the emittance map is involved, that is.

The page that you reference talks about color mixing in a different color space, like paint on paper. In RGB space, blue (0000ff) + yellow (ffff00) is white (ffffff) - and that’s what you get on that picture, multiplied by some small factor that makes output gray.

RGB color model - Wikipedia

Well, when I tried LPV? it was the walls who had difefernt coulours thus when the TOD changed the colour of the walls changed mixing the diffused lights cast on them. The Balls in VXGI were emissive balls meaning they were the light sources. Does that mean, the diffused lights on walls from light emissive sources don’t mix up while if I try the same case as in LPV where the walls were painted in some coulours then teh mix will happen like in paint? Or is VXGI diffeernt than LPV and more accurate?

[anonymous_user_7c71c8ec]

@;310871

Well, when I tried LPV? it was the walls who had difefernt coulours thus when the TOD changed the colour of the walls changed mixing the diffused lights cast on them. The Balls in VXGI were emissive balls meaning they were the light sources. Does that mean, the diffused lights on walls from light emissive sources don’t mix up while if I try the same case as in LPV where the walls were painted in some coulours then teh mix will happen like in paint? Or is VXGI diffeernt than LPV and more accurate?

I think VXGI and LPV should behave similarly… but the experiments that you describe are different. In the balls case, it looks like the light from the balls is mixed on a white wall. In the screenshot with boxes and daylight, it looks like a yellow box is illuminated by direct and reflected sunlight. The incident color is multiplied by surface albedo color, which is not white, so the output color is different.

Specifically, on picture 2 of set (://imgur/a/VGQnS), the floor reflects cyan (00ffff, well almost) and that cyan is multiplied by yellow albedo of the box (ffff00), which gives green (00ff00). On the third picture, red light from the floor (ff0000) is multiplied by yellow (ffff00) and that gives red (ff0000).

[Zero-Night]

when you update the engine, could you see if merging https://github/EpicGames/UnrealEngine/commit/ef2256631b3a54fb615cafe22662b2f929189de8 would be possible? It’s not in the official 4.8 branch yet, but it is a significant update to LPVs. The main changes are that it adds spotlight support and directional occlusion. Always a good idea to keep both systems up to date, for lower spec machines to be able to run the game.

I also just noticed the Nvidia branch updated with : /tree/Turbulence-4.7.6

I was under the impression that ApeX Turbulence’s functionality was already adapted in some way in-engine for the GPU particles. Does anyone know if there’s a significant difference between them?