then, I guess, its time to (at least for lumen, if we specify it) also take that into the depth-buffer.
The implications and problems arising from this are big, since it practically “forbids” the usage of any animated material and similiar things with translucency or masks.
Even in my simple case, I only have 3 choices:
Leave it as it is
Use an opague material and lose the animation in the laser
use a mesh instead and World Position Offset? (probably not good for performance, if I had to guess.)
I feel like it’d probably be more practical to just have Lumen skip screen traces for some surfaces. Evidently this can already be done at some level, as Lumen is doing it for two-sided foliage as of 5.1. Regardless, if this can be fixed in a reasonable way I’m sure the Lumen team already has ideas, it’s not like this is an uncommon or unknown issue.
It’s at 500 because if I want to achieve some kind of illumination in the floor, it needs that. But even if I still don’t understand why it’s going through the black “walls” of the lamp, the emissive lighting (which anyway is highly recommended to avoid use) is the least of the problems.
You could just use the rect light in the light fixture (enable affect world on it)
You have halos around meshes because you’re using the old deprecated ray traced shadows.
The grapes are completely black because they are tiny assets scaled 15-20x, if you reimport them with a uniform 15x scale, they will have color in reflections.
EDIT:
I have tried the grape trick but didn’t work. Even I tried with 3 simple spheres with 1:1 scale. It they are directly illuminated, they are colored, but if not, they are almost black (in fact, it always showed a veeeery barely visible color, not fully black, I think):
EDIT2:
I have noticed that the white-halo problem is related to the Source Radius (or the Source Angle, in the case of Directional Light) of lights, when RT shadows enabled, as you pointed. The higher the value is, the higher the halo is too. If Radius = 0, halo = 0.
Even with a recent source build of UE, I haven’t experienced the halo problem at all. I’ve tested out traditional shadowmaps, VSMS, RT shadows, and DF shadows just to be through.
question about reflection. In the Matrix scene, the reflection of the buildings looks wired. the nearby buildings’ reflections look great, but it looks wired for buildings that are further away. I was about to try to use “r.Lumen.DiffuseIndirect.MaxMeshSDFTraceDistance”, but it doesn’t work in 5.1. It worked in 5.0 I guess.
Does anyone know how to fix this? Thanks
It still works. r.Lumen.TraceMeshSDFs.TraceDistance
Won’t do anything here though, the city sample has mesh distance fields disabled and you’re using hardware raytracing. You can try increasing the Lumen trace distance in the post process volume, however I’m not sure how this behaves with lumen in hw raytracing mode.
I know exactly what that is, assuming you’re using hardware RT. Geometry around the player is put into the persistent lumen scene, with instances being streamed in as you get closer and streamed out as you get further away. To avoid super obvious pop-in, the traces hitting an object on the edge of the lumen scene are dithered to hide the streaming.
I believe there’s some CVar to disable it, but I’m unaware of what it would be. Either way, this isn’t really an issue you’ll face when you’re actually playing the game, because that dithering is meant to hide the transition to the far field, a bigger, lower-res lumen scene component that covers the terrain in the distance. The reason the dithering is so obvious is because it’s just dithering to the sky, but in play mode it should be much harder to observe.
Do you have any other info on lumen 5.1 vs 5.2 or notes on 5.2 lumen? I cant find docs on 5.2 to see what the differences are. Mainly, I am unsure if I should upgrade my 5.1 project to 5.2 for lumen improvements…or just stick with 5.1?? Thanks for any info!
The UE5 roadmap has notes on the lumen improvements in 5.2, and they consist largely of character lighting improvements, supporting translucent reflections of any roughness, and lighting precision issues. Basically, you’re going to get better short-range AO, character lighting, and lighting will be less leaky in general.
The current version of UE5 in main supports those features in addition to multi-bounce lumen reflections, lumen reflections working with lightmass, myriad performance improvements, height fog in lumen reflections, and more I am likely forgetting.
There are definite improvements in 5.2, but if you’re asking if it’s worth migrating your project, that will depend on your use cases. SWRT reflections got much better in my testing, so that’s a pretty fair plus.
Thanks for the info! Hopefully they will release proper docs on Lumen changes soon, seems odd they have not for this release…makes UE feel in constant beta, not stable, which does not help when trying to make the case at VFX studios to use UE for shots.
As Blackwell pointed, I think 5.2 is overall better (but still in “beta”-preview). Anyway… there are still so many bugs, regressions, etc. It’s difficult to say if it’s better to upgrade or not, as you may encounter new problems. If you are planning to release your “game” after one year, maybe it’s ok, because they will be solved, but if you are pointing for a closer release date… I couldn’t say, but I’m still on 4.27 because of some regressions in UE5, until I consider it “production ready”.
The product board is honestly the best you’re going to get for now in terms of new feature explanations, until 5.2 official release at least. Since Epic has been moving to up the cadence of release dates, I think releases are going to be more frequent and more buggy, which may be all right for now. So much of the technology they’ve introduced changes the paradigm of game development so much, I could imagine a lot of it is still very much in flux.
By the way, I also wanted to ask the lumen team if they would be open to reconsidering the implementation of voxel cone tracing for SWRT reflections, and their thought in general on its’ potential utility. In the lumen presentation, you mentioned the reasoning for ditching VCT was its’ bias towards either over-occlusion or light-leaking, and that the pipeline could only support SWRT.
While I absolutely agree that VCT has obvious failure cases and cannot support several different features of lumen, I think the ability to trade noise for over-occlusion/leaking would be an asset. In a handful of lumen tests I’ve conducted, it’s hard to impossible to use rough reflections in indoor scenes without astronomical amounts of noise. That being said, I also know there are CVars that can help resolve/mitigate some of the apparent issues with noisy lumen reflections, and I would be very grateful if the lumen documentation could be updated to touch on some of these.
