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.
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.
@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.
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.
Ray tracing is not good enough performance wise. It has a extremely bad visual to performance ratio when compared with alternatives.
I’m not talking about screen space reflections , I’m talking about a better fallback than cubemaps. Skylight with SDF specular occlusion would just have outlines rather than Lumen reflections having issues like black objects and voxel imprinted textures issues.
Skylight with SDF specular occlusion would act as a major replacement for cubemap fallback in large worlds and could(need Daniel’s opinion) cut out computations lumen reflections have while have a more subtle photorealism approach. I Imagine tracing SDF is not the most expensive part of lumen reflections but Daniel would know more on that.
cubemaps are the proper fallback for relfections. it’s real environment textures that reflect. a skylight (directional is sharp, ambient is soft) even with sdfs blocking it will give you just a basic gloss or just ambient mud.
on the brink of asking engine coders. what would be the proper way to add dbuffer decals to glass refraction and reflection? translucent z prepass? render the decals into thin air. then composite? a nice challenge. hmm
If combined with a method like stochastic SSR, should work in the majority of basic and common gameplay while keeping a strong sense of photorealism.
Most of time, (its gets pretty raining where I live) outside puddles are usually the color of the sky and RL materials are just darkened with “basic gloss”. IRL, you have to try a lot harder in games to break this design. The visual to performance ratio is much better than current options in the games we have now.
That’s actually exactly what the old DFAO implementation did- it handled sky occlusion as well as specular occlusion via bent normals, although I don’t think it had the same ray tradeoff capabilities as lumen does now.
That said, if you’re using lumen GI, disabling dedicated reflection rays but keeping SSR and the rough lumen probes gives you good results for basically free.
I feel like Teardown is an excellent game to demonstrate what that looks like: It has full sky occlusion for both diffuse and specular; in outdoors areas it can be enough for a decent look, but it basically means no reflections at all in many scenarios.
My immediate thought was to use the “Static Mesh Decal Function” which is a material meant to be used on a translucent box that basically does depth reprojection to create UVs for decals. But it appears that raytraced translucency is having issues with the function because it can’t properly sample the scene depth. Plugging it into a scalar debug node output a flat value of 1,000,000… but its just black. With that node broken, I don’t see any way of using depth reprojection to create a decal.
If it did work, then you could use it in place of dbuffer decals - or what I’d probably do is use the dbuffer in the main pass and make the decal function only visible in RT (since dbuffer has more features).
Annoyingly RT translucency is all or nothing. AFAIK so you can’t set the decal function box to be raster while glass is RT to get around the bug either.
Not sure if there’s a good reason why you can’t mix raster and RT translucency in the same PPV but I really think it should be allowed. I’d like to be able to pick and choose… But that aside, the bigger issue is that the scene texture/depth nodes appear broken in RT translucency.
Until one of those two things are fixed, the only way I can see it working is if you had a conforming mesh with an opaque masked material that has the decal texture on it and lined it up closely to the real decal, kind of like this image from the mesh decal documentation:
yeh… you can’t just render something in the z pre pass and hide it in the base pass. i’m aware of that. this would also create discontinuities if you’d have a decal on a surface behind the glass. either way i need full dbuffer access in the t pass. at this point the gbuffer should be free to use. my goal is to get the decal normal into the glass. maybe some shiny blood splatter on it. lil bit of rated r action. tlou style. hmm
You can write the glass to the custom stencil, then place/spawn a flat transparent plane with the blood textures on it. Can be forward shaded so you get roughness and normals. Use the custom stencil to hide the blood splatter anywhere that isn’t the glass, and place/spawn a dbuffer decal in the same spot to draw the blood on any opaque surfaces if needed.
This will handle basically every case that the glass is a flat plane - which is probably most cases overall - and the masking will help prevent floating textures when the decal might extend beyond the glass (like with a broken window).
This isn’t the place to get into the depths of the dbuffer so I’ll just leave it at that.
yeah… i think ima ditch the idea. taa/tsr is not having it, either way. it can’t handle the motion of the details. dunno if it’s the reflection or “refraction” (not even enabled there).
Enable draw to depth and velocity in the material. It’s because the motion vectors are from whatever is behind the glass, causing TAA to over compensate and wig out.
okay. that works. cool. i changed the shatter material approach anyway. and it still breaks, cause actual refraction is screenspace. this works for fp but not tp games.
