Have you tried 5.1? The reflections are stable in both eyes VR in 5.1 with Lumen enabled and openXR.
Yes I did! In fact, one week ago we have finished a project in 5.1 and another one in 5.2. You are rght in 5.1 there were less reflection glitches, but I think I remember there were too. And also other issues related with ray tracing and lumen.
done some testing. stochastic ray shadows that is. looks good on static geo.
lil noisy with moving objects. it’s stochastic. aka randomly sampled. i get it. i take the performance plus. more work for taa tho. (and it’s not doing too good on certain ray traced things. like mirrors. the motion doesn’t mirror correctly. the further the object thru the mirror the more it’s ghosting. that’s a whole 'nother problem tho.)
subject 2 exposes hard shadows on dithered hair. works with the normal ray shadows or shadow maps. dunno vsm. too much resources for my rig. also seems the light reflection on the hair got more unstable. hmm
and i know windy foliage doesn’t work with ray shadows. (there’s a workaround for that, being rigged trees, but that’s beyond topic. also visible are the earlier mentioned backlighting artefacts even with enabled fog sampling.)
bonus snap. i never checked if volumes are working with shadows. looks good tho. i wish there was a way to make the volumetric cloud to cast a shadow. that’s stochastic raymarching? 
1 Like
Just tested - for me its the left eye. Right eye looks good. Quest2+Link+openXR
This is very, very exciting! I’d have to imagine that stochastic shadows (or sampled direct lighting, or whatever other name they chose) will take a few engine versions to get to a strong enough point to be shippable, but the results you’re showing now are already very promising. I know that stochastic shadows ostensibly allow for using screen-space/distance field/hardware rays all in the same shadow paradigm, but I’d love to see what the perf numbers look like with that.
If most of your shadowing is being done on-screen, then shadows could be significantly cheaper than if they need to do a lot of offline ray-tracing. You could also probably tag which objects receive full RT shadows vs. just SS shadows, so stochastic shadows could have a number of great levers to manage performance.
Side note: Personally, I prefer the name stochastic shadows over some of the other ones I’ve seen mentioned. If it’s a matter of copyright or expanding what the technology does, I completely understand, but I feel like it’s catchy and easy to rememeber.
i got a limited budget and limited test assets rn. in my foliage spam torture…
8k csm
random rays (it’s not really random) cause it’s a single sun light.
not the most accurate perf measure, cause it’s instance bound struggle. but fidelity compares. much more details for less compute.
the real benefit of this are proper contact hardening shadows (i showed in the first test screenshot in the other post). dunno vsm. shadow maps don’t even do that. so there’s no reason to compare this screenshot and perf numbers. just gotta say 6 lamps with all those shadows runs and looks great. ez 60 fps. (seems the editor is locked on my rig/config) i should do a more lightspammed map? i can do that.
edit: nvm… i can show you atleast those perf numbers. pure ray bound. only diffuse and full metal…
pure rayshadows (and 8 bounces of goodness:)
and stochastic ray shadows
the stochastics are a lil noisy when not fully stabilized, but… that’s where actual environment art and textures come in. you won’t see most of the noise on detailed textures.
1 Like
Virtual shadow maps actually do support a form of contact hardening with their Shadow Map Ray-tracing algorithm. It’s not nearly as robust as actual RT shadows (all of the documentation describes it as plausible contact hardening), but you need to increase the ray count of the VSM sampling beyond 1rpp, or it does default to perfectly hard shadows. You likely know this already, but others may find the context helpful.
That said, there is a lot about the VSM pipeline that I don’t understand. When I was trying out the wild west megascans map that Epic provided around 5.1 or so, VSM performance made the scene almost unmanageable by default, but enabling RT shadows significantly improved performance.
Arting around technical issues is the bread and butter of our trade. It still amuses me that lumen can easily handle the highly-specular surfaces that would have broken cubemaps, and yet the normal material roughness for objects built with cubemaps in mind, will break lumen.
that is raytracing in a nutshell. roughness adds complexity. when you hit a rough surface you have to decide which way the reflection ray goes. in the pathtracer multiple reflection rays are generated and collect the color of the surroundings to blend. that’s not gonna run in realtime anytime soon, tho. for the game performance rn only one random ray is cast per frame and those random rays are accumulated over time via the history and are temporaly stabilised.
the cheap method for adding roughness was using irradiance cubemaps. more rough more blurry. they are not updating tho. so you get a static cubemap at build time.
i think we surpassed that stage. rough reflections can update in realtime at moderate quality. artist discretion. you gotta know where it fizzles and avoid it. ez.
The multi-light case you show is a really big deal imo because it addresses a case that has been mostly impossible to get acceptable performance on - realistic chandeliers and similar multi-light fixtures.
In my house I have chandeliers with 6 bulbs. This setup casts very distinct shadows, but replicating this look in engine by overlapping 6 light attenuation radii with shadow maps is a big no-no. You end up putting one light in the middle and lose the distinct multi-shadow look. Most people probably don’t notice… but I notice and I’m looking forward to trying it out. Not gonna build though, I’ve given up keeping up with main. Too much storage space, too little time lol.
@Miguel1900, @maxbrown Have you tried disabling instanced stereo? Generally when dealing with VR issues that are present in just one eye that’s the first thing we test as sometimes when a new rendering feature is implemented often the stereo optimisations come in a later engine version / update. Its not optimal as it costs a bit more performance but for some use cases it might not be an issue.
You may want to let NVIDIA know about that; they seem hell-bent on making real-time PT a reality for PC at least. I have a pretty beefy card (4070), and while the performance isn’t nearly good enough to work on consoles of GPUs out there, I am genuinely loving the experience. When the awe factor wears off, what you’re left with is a visual presentation that just works. Alan Wake 2 with path-tracing is a very subtle implementation, but it shows off that path-tracing can easily fade into the background and just plus the existing art quite well.
This is one of the reasons I find myself loving IES profiles as well; it’s able to handle so much of that complex radiometric behavior that would be either far too complex or expensive to do in-engine. I feel like the technology current and upcoming (nanite+lumen+stochoastic shadows) will allow for such a richer visual presentation than we’re used to in most games.
I seriously feel that on the builds. After that 370GB build, it’s just no longer feasible unless I do more research into how to cut that size down.
i thought i wrote that down already. set development editor (should be the default even) and in the solution xplorer you only build UE5 not all the other tools. this is also mentioned in the offical build guide. you can compile the tools later or if you require them. like lightmass (or build/package tools - maybe not). they are not essential for the function of the editor.
this should get your size down to roughly 230 GB. plus a couple for lightmass or whatever you need.
1 Like
The fact that 230 GB is after trimming is still amazing to me, but thank you so much. You did write it down, but I didn’t quite understand the directions; this clarifies things for me. 230 GB I actually can afford storage wise, and I certainly don’t need lightmass for anything. Thank you!
I did what you said; interestingly, the build is taking far longer than normal. I kicked it off last night, and it’s still going strong at 1229/6000. Not an issue, just fascinating.
okay. not sure why it’s taking longer. make sure it compiles at full priority and uses all or most of the cores. i had 2:30 hours at average 80 percent cpu (6c/12t) usage. all while still using the machine for some browsing and chatting. on your 8c/8t cpu you should be done in about 3+ hours, estimate.
The build actually finished up just a bit ago;successful too, shaders compiling as I write this.
UPDATE: Total size is only 180GB, way smaller than that 370 GB
2 Likes
Default sorting in 5.4 appears very messed up. No settings changed from 5.3 to 5.4.
With fog disabled, light shaft behavior is as normal. Volumetric fog specifically is the culprit, the shadow type makes no difference.
@Daniel_Wright Sorry for the ping. But you’re the expert on this particular subject and would highly appreciate some of your consultancy on the matter.
Take a look at this 8 second clip showing SSR to cubemap fallback compared to RT reflection.
Most of the specular fallback in the cubemap is just sky and that would be fine if it wasn’t for the nearby wall and some other objects too centered to be included in the cubemap. I was wondering if generated SDF’s could work as a specular blockage for skylight and nothing more? Where that design would help the jarring inconsistency in the cubemap scenario without the perf hit other RT(SWRT) alternatives would incur. Would that design strike you as a small performance lift to lumen reflections or similar performance to DFAO?
If you believe that would be efficient, that might serve a lot of project looking for budgetary friendly options over full Lumen reflections with the voxel and other logic etc.
EDIT: After some replies, I have concern I didn’t describe what the design I’m talking about would look like. You can replicate the effect I’m talking about but culling all surface cache(to appear black).
i reckon the cubemaps are angle corrected. this a bit of math already. marching the screenspace and backtracking the geo normal will just add more load to the mix. i don’t think there’s any performance gain available. screenspace is just screenspace. better off for certain scenerarios. raytracing looks a lot cleaner.