I have noticed that unified lighting does take quite a bit longer to load.
Starting a game in studio often causes lighting to take a solid 5 seconds to load in,
even on my workstation computer which is powerful enough to run every game on ultra.
There seems to be more overhead or “start-up lag” with the new lighting.
Is this on a Windows machine by any chance?
It is on Windows indeed, I also have Direct3D11 selected as the graphics backend.
Not sure if that makes a difference but it’s just been the default for a while since it runs most stable.
There’s an incoming fix coming with the next engine build for speeding up Dx11 placefile startup in general. Would want to clarify if you meant something else seems slower though?
As far as I know it is only the lighting and PBR graphics.
Shadows are entirely invisible the first couple seconds before they pop into existence.
Everything else seems to work as intended as far as I’m aware.
I opened an empty baseplate with only a few simple objects present, technically speaking it should load extremely fast, especially on a high-end computer.
This is fascinating. Shadows and lights should all appear within the first 70 or so frames (unless lights are being streamed and not yet in your local DM), would appreciate if you could try to send over the placefile or a MP dump of how long frames take.
Would help to know FPS you’re running on.
I didn’t even know this light blurring thing was a thing, I am going to be using this for my game!! Thank you!
Is changing the light rendering max distance a thing?
AT LONG LAST, FINALLY! I don’t have to worry as much about the way it looks on different devices!
I haven’t read through the whole post yet, as I don’t have time at the moment, so quick question: What is the real difference, and what does this mean?
To really condense it down, lighting as your camera gets farther gets blurry around shadow edges, and this beta stops it
Now that I think about it, why can’t we just have lighting stay at its best quality at any distance?
Oh wow, exciting! Thank you! I’ll look into this. 
Performance! If lighting everywhere was constantly sharp, it would make lighting significantly laggier. If you have ever had a game with a ton of active lights with castShadows on, you’ll know how awful of a performance impact it would make for example.
I figured, but it should atleast be an option imo
That’s incredible! The shadow detail getting lost in mid-distance to high-distance objects always felt odd to me, but now it’s way better.
This is frickin’ awesome. Good work fellas!!! Can’t wait to be able to use this in live experiences.
Does this mean in the future voxel, shadow-map, and future will all be combined, and does this mean volumetric lighting is on the WORK?? i really hope that volumetric lighting will be a thing soon.
TLDR It would be great to fix water on phone and console looking horrible
This is a really great thing to point out, and it’s definitely something that I have encountered myself before. But this issue isn’t exclusive to Roblox but in other engines like Unreal Engine 4 and Unity as well.
The main issue lies in the GPU workload and how it scales with distance. Extending per-pixel shading (like PBR) indefinitely is impractical because, as objects get farther from the camera, they occupy less pixels on screen. Despite this, the GPU would still need to calculate the more complex lighting and shading for these tiny areas, which quickly becomes inefficient.
This is conceptually similar to why “Quad Overdraw” happens in 3D engines. If you do not implement some kind of LOD system for distant meshes with very dense geometry the GPU might end up shading many pixels that contribute very little to the final image. Without LODs, these computations can cause significant GPU slowdowns, especially when dealing with complex shaders.
In Roblox’s case, the voxel light grid very likely plays a role here. Roblox engineers knew that Voxels (especially at the time of when Roblox first released on Mobile) are just very performant and cheap. Since Voxels are aligned to a world-space grid rather than relying solely on per-pixel lighting and also being able to be calculated on the CPU, they are quite efficient and don’t need very strong GPU’s, but due to voxels being very “coarse” there is no real way to properly implement PBR/specular lighting. Now at one point they did have a technology called “VoxelGPUCascaded” when future is bright was in the beta phase, this technology did have specular lighting for voxels, by having voxels be done on the GPU and also having the voxels be in a far more smaller size, meaning they were more “accurate”. But the technology was scrapped because the mobile user base at the time, would just not have adequate enough performance to support that technology.
So what happened is that they just decided to use future that we have today, and use a “hybrid” approach to fade out the distant lighting and fallback to the underlying Voxel system.
Anyways I guess that’s one way to explain it, I might be a bit incorrect as I am not that experienced with 3D graphics to such a low level yet.
nice
Let There Be Light 
