Originally posted by Gandosh
View Post
Announcement
Collapse
No announcement yet.
NVIDIA GameWorks Integration
Collapse
X
-
Originally posted by Mike.Skolones View PostHi 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
Originally posted by Alexey.Panteleev View PostThe 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.
Originally posted by Alexey.Panteleev View PostWe 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.Though to be clear I multiplied the total transmission of the cone by the ambient lighting.
Originally posted by Alexey.Panteleev View PostWe 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.
Thanks for your help!
Comment
-
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.
Comment
-
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.NVIDIA GameWorks merged branch (v4.9.2) (v4.12.5) (v4.13 p2)
Feel free to Donate if you wish to support me
Comment
-
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.
Comment
-
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.
Comment
-
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.
Comment
-
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.NVIDIA GameWorks merged branch (v4.9.2) (v4.12.5) (v4.13 p2)
Feel free to Donate if you wish to support me
Comment
-
Originally posted by PLASTICA-MAN View Post@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.
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
Comment
-
Originally posted by Alexey.Panteleev View PostColor 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
Comment
-
Originally posted by PLASTICA-MAN View PostWell, 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?
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).
Comment
-
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?
Comment
Comment