This was in 5.3.
I suspected that was the case, but didn’t notice any change when messing with the translucency volume resolution so I wasn’t sure. Very exciting though, even as is. The loss in quality is a non issue for most use cases I’d want refraction for anyway.
I tried this link and it doesn’t work. I also tried it a few times in the past as well. And it never worked. I get “This is not the web page you are looking for”
Works fine for me. You’ll need to be logged in to GitHub.
I see. Thanks. But it’s strange from their side, because I actually get more info:
Page not found.
404 This is not the web page you are looking for
Exactly like an error. While they should have said something like : You cannot view this page without being logged in.
EDIT: Nah, spoke too soon. Even logged in I get the same error. Strange.
Might you be willing to walk me through how you got it to work? Materials, CVars, etc?
The cvars are:
r.RayTracing.Translucency.EmissiveAndIndirectLighting
r.RayTracing.Reflections.EmissiveAndIndirectLighting
It appears refraction method may need to be set to IoR (even if just set to 1.0), but other than that there doesn’t need to be anything special in the material.
Unfortunately still not interacting with lumen for me:
Materials very close to opaque to show effect. Indirect lighting still not visible in material, IOR in use, CVars enabled.
Also, didn’t catch this until now:
It looks like Epic is implementing its’ own ReSTIR-style many light shadow system, Github update as of about a week ago. I wonder what this will mean for VSMs, but it’ll be interesting to see how it develops. Epic had something along the lines of this in 5.1 as experimental lumen direct lighting, but I suppose this is more generalizable.
From my testing so far, only the transmitted rays get proper GI. The reflected rays are receiving some GI but it’s definitely not the same as the translucency - not sure why. If you disable the the GI, areas like the underside of the roof will turn totally black since they receive no direct lighting. This GI appears to be the same as the depreciated RTGI.
But if you make the object completely translucent, you will see the lumen GI volume properly. This is very noticable if you toggle the effect off.
I’m still experimenting with it to see if there’s something I’m missing. But so far it just seems like transmitted rays get lumen GI but reflections on RT translucency don’t in 5.3.
In practice, I didn’t find this noticeable, unless the glass was mostly or completely opaque. I did notice it sort of lets you hack using RT reflections in a scene that is otherwise using Lumen reflections by making mirrors out of translucent materials - which is kind of interesting.
To get around the lack of lumen on the reflected rays, I tried hacking the refracted rays to act as reflections. Doing this allowed for opaque mirror reflections that were not splotchy since the translucency volume is too low res to have the noise typical from indirectly lit Lumen scenes. I thought maybe the low detail volume may be a worthwhile trade in some cases. Unfortunately there was a significant flickering artifact from my janky way of doing it that made it functionally unusable in motion, but I can show an image of it later just to show what it would look like.
Got it, that makes a lot more sense to me, thank you. It is interesting how the different new/legacy systems are interplaying with eachother like this, and I eagerly await the lumen team’s front layer refraction system, or whatever it turns out to be. I was just having a conversation with a friend about how lumen has achieved parity with offline renders when it comes to a lot of opaque light transport, but refraction is still something it cannot handle well. It’ll be interesting to see how that may change.
Would appreciate it, thank you.
As promised…
Lumen Mirror Reflections:
But you can see the overall brightness of the scene, and color are a reasonably close match to the Lumen scene. You still get some larger scale noise which can be reduced by messing with cvars and flickering.
Also, you may have noticed it says Emissive and GI… So here’s some eye candy showing off the RT refraction + emissive and indirect lit only scene. This is genuinely cool, even if its a bit leaky and imperfect.
10 years ago this would have taken an offline renderer and who knows how much time. Instead, it’s real-time running in what’s ostensibly a game engine. This is incredible!
Noticed a minor bug in 5.3.1: Specular highlights from light actors aren’t occluded in HQ translucent reflections, but works correctly on opaque surfaces.
This is kind of of a follow up after Lumen Direct Lighting. Lumen DL didn’t deliver good enough quality and it was questionable to have direct lighting depend on indirect (like how do you scale down?).
VSMs will be the superior solution for hero lights like directional (sun). Stochastic Shadows are aimed to provide a reasonably cheap replacement for baked shadows from local lights.
It doesn’t use ReSTIR due to extra performance overhead of ReSTIR for ~100 lights (which seem to be reasonable numbers for console games) and blurry direct lighting. ReSTIR stochastically evaluates not only shadows, but also BRDF itself. So you need to run denoising on top of BRDF causing blur and ghosting in unshadowed regions.
do i wanna know how this works? was just messing around and lasered a chrome ball. somehow at the million cd i blasted thru it and it created a second hit point.
this has no real usage, atm. cool to see it kinda working tho. not a disco ball yet. lol
btw… why are there no colored shadows in the engine? this shot is shadow mapped aka standard cascade. it could pickup the color and opacity of the glass for a blend. rgba4 is a thing. good enough for a proxy color without much resources.
If you’re desperate for colored translucent shadows, you can use a capture component aligned with the sun to grab the color and depth and re-project the color using a decal with emissive.
It works by basically creating a custom shadow and color map for a single object or collection. It’s not particularly cheap and should be used sparingly, but for scenes that absolutely must have dynamic colored translucency it is an option. Due to relying on decals, the light bounces is screen space only.
Edit: I’ve set up a full tutorial for those interested
pt. 1 https://youtu.be/Xe5TjsUtmZs
pt. 2 https://youtu.be/A6n2iF0nxZw
That’s a good idea! I solved this a sort of different way a while back, by using a ray-plane intersection. Still requires a capture component for depth though:
I used a translucent card attached to the camera instead of a decal because I wanted multiplied color, and evidently the modulate blend mode for decals is non-functional by design. 
I see, so a reasonable use case would be a VSM sun light, perhaps VFX lights, and all else would be stochastic shadows? Is the ray count going to be something tunable via PPV, or is it more meant to be a project-wide setting? Is this (theoretically) something that could scale down to mobile?
So this is strictly shadows, no lighting integration.
For now it’s a CVar, but it’s also very early days of this feature. Not sure about mobile, I guess on some HW?
Shadows are stochastically sampled with a constant ray budget per pixel. Lighting is evaluated fully every frame. It’s also quite bit faster than current lighting loop, as it leverages similar work which has to be done to decide where to actually trace rays.
I guess at some point I need to start a dedicated thread :).
A good idea, I don’t want to make the lumen thread any messier than it already is. I’m very excited by this feature, as I’ve found the extant shadowing solutions to form a pretty strong gulf between high quality-high cost (RT shadows, VSMs especially) and low-quality low-cost (standard shadowmaps, SSShadows, DF shadows variably). A unified lighting method that could scale from DF shadows to HWRT shadows could also make development costs easier.
