Everything we are discussing here is based on DXR (DirectX Raytracing API). UE4 raytracing is based on this, with an alternate path using Vulkan(with card OEM extensions). Therefore, if your card does not support the Ray Tracing features of DXR, all this stuff will not work.
I know not everyone is made of money or can afford new HW, but Nvidia’s RTX based HW is now selling for as little as $349 US for the 2060, all the way to $1200 US for the 2080 TI. So you have some options if you want to explore ray tracing with UE4.
It makes little to no sense have RT available as a custom CPU/GPU solution for UE4, considering the HW will be widespread within a year (and will be cheaper and faster). Best to buy the HW or wait to see if your GPU vendor supports it as a patch to existing drivers somehow.
Translucency looks great, as we saw in SpeedLight DEMO. If Mask and Foliage and HISM can be supported, Landscape can be supported, then we can start to use DXR technology in 4.22.
That’s not raytraced translucency. It’s a (still very nice) shader sampling a cube render texture: https://i.imgur.com/kvHlUyb.jpg
The real benefit of raytraced translucency is that it’ll wipe the slate clean of all of the existing buggy UE translucency stuff. It should look pretty close to what we saw above though.
Hmm. but that is not the implementation we are discussing here. I see that it is running on NVidia’s branch for GameWorks… I gotta check that, but I don’t think it is released already, there is a long time I don’t mess with GameWorks.
Btw, at that specific timeline, we can see several black artifacts in the distant background scene, maybe those are result of a lack of tweaking in the scene, and probably is, but so far I am really looking have some info from Epic staff about the implementation we will use from Epic instead of that one with GameWorks.
Maybe someone watching this thread and messing with GameWorks could confirm this is released to the public already?
Lightmass baking is pretty much all about tracing a huge amount of rays. The RTX cards have hardware accelerated raytracing. Obviously, a Lightmass implementation using DXR would be, at the very least, 100x faster.
Firstly, you wouldn’t want RTX results going into a lightmap. They’re nice, but at the same time they’re not that good and are still just a general estimate of how real light would look. Their entire upsell is in the “realtime” part. So that means you have to run a better looking offline renderer on the GPU. Right now that means path tracing.
For a while I was working on a GPU accelerated path-traced lightmass replacement for UE. Not only was progress difficult, the results weren’t all that great unless you spent a week rendering your lighting. That product made it into Unity in a different form where I believe it’s still just a viewport renderer.
People underestimate just how much work is done when you bake the lighting for a level. It’s hundreds of thousands of times more work than simply raytracing a scene to a viewport, realtime or not. To get a good result from path tracing you either spend more time building the lightmap (even with GPU acceleration) than you ever world running lightmass, or you rely on a denoiser, something that has really only just appeared on the scene. And the denoiser is part of why RTX results aren’t worth pushing into an offline lightmap. In the next couple of graphics card generations realtime graphics like this are very quickly going to reach a point where the denoiser is both obvious and the results are not good enough. It is a temporary solution.
Hopefully RTX gives Epic enough tools to write a CUDA version of lightmass, but I’d wait and see what they say about that as it could easily go either way.
Here are the tests with reflection multibounce, its fast but visually really dissapointing (for now), the reflections only seem to reflect the reflections and the indirect baked lighting (from skylight, etc), no dynamic shadows or AO at all…
Well it won’t be on CUDA, because that’s Nvidia specific. Nor will the new lightmapper be RTX specific, instead it appears to be some accelerated raytracer that doesn’t rely on final gather (one hopes).
I would expect that, at some point and quite possibly right out the gate, the lightmapper will get DXR support, possibly for previews, baking, or both. RTX is, again, Nvidia’s buzzword for Microsoft’s DXR standard. The DXR standard does however bring many nicities for raytracing, and RTX’s fixed function BHV block will probably be supported as well.
We’re using the terms interchangeably in this conversation. We know that Epic will product a platform agnostic tool eventually if it’s possible.
GPU accelerated BHV is key to this generation’s realtime raytracing performance so if there isn’t an agnostic equivalent, then yeah, it’s going to be an Nvidia-only solution until everyone else gets their act together.
Secondary bounces usually don’t show unless you’re in an otherwise unlit room using an overly bright directional light and your exposure is turned up. At least to me. I wouldn’t notice it in an outdoor scene.
Typically your secondary bounce has the effect of lightening the entire room just a touch, with further bounces giving you a more smooth result.
Hello, I haven’t had time to test new branches. Can Mask Material be rendered by DXR now? Now the branches look translucent and GI have entered the testing stage, but can Mask and Foliage, Landscape render normally in DXR?
