NVIDIA GameWorks Integration

[Alexey.Panteleev]

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?

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]

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

Great, thanks! This is just for fun, but here's a build: http://www.scheidecker.net/BrickGame...6-12-17.00.rar

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.

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

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.

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]

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

[Mike.Skolones]

@Alexey @Mike 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.com/show...l=1#post309958

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

[GalaxyMan2015]

Problem isn't the propriety code, its the actual integration, they are heavily integrated into the renderer, at this 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 here 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 this 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.

[GalaxyMan2015]

I agree that this 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.

[Alexey.Panteleev]

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

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: http://imgur.com/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 : http://www.enchantedlearning.com/cra...ormixing.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 here: http://i.imgur.com/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 : http://imgur.com/a/VGQnS

Effectively colours do mix and the results are like here : http://upload.wikimedia.org/wikipedi..._simulated.png

Here is a video : https://www.youtube.com/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.

https://en.wikipedia.org/wiki/RGB_color_model

[Nudlegaru]

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.

https://en.wikipedia.org/wiki/RGB_color_model

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?

[Alexey.Panteleev]

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 here 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 this set (http://imgur.com/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]

GalaxyMan, when you update the engine, could you see if merging https://github.com/EpicGames/UnrealE...62b2f929189de8 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 this: https://github.com/NvPhysX/UnrealEng...rbulence-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?