Again, reread my description: default project, I made no changes. To ensure I didn’t muck with something under the hood, I resorted to using a default project with default materials (the worldgrid) and still get the same results.
I am very-willing to admit I can make a mistake, point of order, I assume I made a mistake before giving this kind of feedback, hence my exhaustive search for configuration-settings; PEBKAC is an acronym for a reason…
If it works for you great, but it’s not working for me, in a relatively straightforward testcase.
What are your system specs, driver versions and OS version? This could boil down to some GPU precision fallback or something.
I’m really not seeing any of these issues in my testing. Maybe test in standalone to see if you’re not just having some editor glitch?(sometimes bugs like this can happen if the editor is sitting there hogging 20gb memory, usually you just have to restart the editor or play in standalone)
Win 10, RTX 4060, don’t recall the driver I was on before I tested but to be sure I did upgrade to the latest 572.16. Tried both game-ready and studio drivers.
Always test in standalone, even package it to ensure it’s not an editor thing.
I know you don’t know me, but I used to be in tech support, so I DO try and run the gamut on things I could have missed.
And not that I don’t appreciate the help but it feels like I am spinning my wheels when I just-really want to run around in some grass.
Pretty sure this is 100% due to RT culling settings and should have nothing to do with Lumen. Disabling Raytraced Shadows in the project settings will do nothing if the directional light is set to override this - so make sure this isn’t the case. Change the directional light to disable RT (or use project settings if RT shadows are disabled at project level), or make adjustments to your culling cvars.
Default RT Shadows:
Oh that was one thing I forgot to check or mention in my previous posts: I don’t use raytraced shadows, because they have a ton of annoying limitations, I only have “use HWRT for lumen” enabled for better lumen.
It seems I DID enable ray-traced shadows on the project; been looking at this so long I missed it.
RT shadows enabled, It DOES seem related to culling/culling-distance. r.RayTracing.Culling.Radius 500000 works, but up close it’s still fugly, check the front of the mountain in the foreground.
So, my take-away here is that one cannot really (effectively) use ray-traced shadows from the sun. I was able to enable RT shadows in the project but disable in UDS…
RT shadows also have “overlapping” issues with Nanite (Nanite landscape?). You could also try cvar nanite mode 1, but it’s very performance demanding and it doesn’t eliminate all overlapping issues.
In summary: I would never use RT shadows as they seem abandoned. Use VSMs or MegaLights instead.
i just rebuilt that scene. my question is why capture all this rvt stuff and duplicate it as this virtual heightfield? i guess it’s useful for things like snow or sand where the clipping is desired but the displacement can be done with the landscape itself, plus the material collision update. and… seems highly unstable in 5.5.2. atleast on my craptop. crashes when viewing the virtual wireframe and it just crashed with a vt feedback error.
either way… none of this is relevant to lumen. raytracing shadows is it’s own tech. i dunno how the terrain is raytraced anyway. is it a giant cluster/chunk collection of bvh? i mean… without any adaptive tesselation or dynamic deformation it’s just a bunch of triangles that don’t need to move. static bvh data. could be rather easy to raytrace against a sun lamp. for sure is alot worse with loads of foliage.
offtopic note 2: editor likes to crash on close or restart occassionaly. not sure why. but it’s an outro not inbetween. : )
Yeah - ray-traced sun shadows are definitely problematic with distant terrain and nanite at the moment.
My current preference is for VSM sun shadows with distance field shadows enabled for far away, non-nanite objects, and MegaLights for local lights. We’ll see how things go once MegaLight ms supports directional lights.
I don’t understand why HW RT shadows disables Distance Field Shadows though. Would be nice if they could take over for distant, culled geometry.
raytracing uses bounding boxes and geometry clusters aka bvh, while sdf is raymarching in basicly screenspace. combining those is i’d guess rather expensive or maybe not compatible. cause screenspace and bvh don’t share data. or you would raytrace in world space and if you hit a bounding box of a sdf volume you would start to raymarch. not sure if this is applicable or if shaders can switch that style of code. i’m not that deep in the engine. i can visualize it, but not code it very well, beyond hobby level. : )
If you’re deadset on using HWRT shadows, there actually is a semi-decent alternative to distance field shadows: far field. Though you have to use world partition and HLOD, if I’m not mistaken, since it samples a lower LOD for the far field traces. Also, it’s an opt in feature per mesh, so you can pick which things you want the far field to operate on.
You can have both on at the same time, just not on the same light at the same time.
For example, here is a scene with two suns, with a light function switching them at a predetermined distance.
Sub 30k units (RT only):
just a lil wip. working with raytraced glass. fragile yo. refraction is a thing. i wouldn’t even need that, here. either way…
i dunno howto adjust the reflection "back"trace distance. the room is not fully showing up in the mirror. (minor note: i don’t have fresnel on it yet.)
also would like an additive for the diffuse part of the crack mask. tlou textures shall not show on screen. the mirror is a half blend rn. works. kinda ps2 style. i’d like to add more to it tho. just a lil.
volumetrics do a funky bit too. they don’t render in the mirror. i know this is “double” the gpu torture.
Results of change outlined below. This allows you to continue controlling lumen with your project settings and post process settings no differently than 5.0 - 5.4
I’m just wondering how to avoid confusion between Unreal’s Path Tracing and Nvidia’s Path Tracing, as one is “offline” and the other one is “real-time.” With Ray Tracing, it doesn’t matter if it comes from one engine or another; it’s just Ray Tracing. But with Path Tracing, almost no gamer knows which one they’re talking about. So, which one is the actual PT? Who is using it fraudulently? How could we refer to Unreal’s PT if the other one becomes the “standard” or more popular?
Additionally, specifically for @Krzysztof.N, I suppose:
Do you know why the new RTX 5000 family is so much faster in Path Tracing rendering compared to “normal” (HW Lumen)?
Notice the left chart (HW Lumen) GPU gaps against the bottom-right chart (PT):
Reference PT is tracing pure paths from a camera and then bouncing them around. It’s basically what you would do if you would want to render an offline movie, where you don’t want any hacks or shortcuts and given enough time it will converge to a perfect result. Kind of, as in real production there’s denoising, ray guiding, caches, DOF added in post process and similar tricks.
Real-Time PT is a hybrid where some things are handled through rasterization and ray tracing, and some parts are path traced. Usually primary rays are replaced with rasterization, translucency is handled using standard techniques like probes or SSR etc. And then there’s a GI and reflection passes which trace some paths, or maybe there’s unified indirect lighting pass which traces paths handling both GI and reflections. Through depending on the implementation this may vary greatly. For example real-time PT in Alan Wake 2 is a mix of baked lighting and tracing short paths.
All of this is not really different from terms like real-time GI, where we have probes relit at runtime (no tracing at all) on one end, and lets say something like Lumen, which is tracing rays from pixels each frame on the other end. Both are both referred to as real-time GI, while they do completely different things under the hood. So as always devil is in the details. Details are complicated and hard to explain, so if anyone asks I tend to use “Reference PT” and “Real-Time PT”.
Now, why X is faster than Y is hard to tell without digging into details of what’s actually happening there. For example in Lumen reflections you can enable multiple bounces and they will trace very long and complex paths, which is quite slow. In general Lumen is designed for consoles and should provide a good tradeoff for that HW, while NV solutions are designed for high-end GPUs and should provide a good tradeoff there.
