Thank you so much for giving a better insight to this! I remember talking to @CoastalStarlight at RDC, asking similar questions as to why there are these limitations.
What I have previously observed when using the ExtendedLightRanges2 fast flag to test out 240 studs light instances are, that these lights with radiuses larger than the pixel lighting rendering radius, especially when those lights are dynamic and actively moving. When parts of the light fall outside the pixel lighting radius, it seems like visuals would break or appear inconsistent, especially in fast-moving scenarios. Basically, the voxels would update WAY too slow, which makes sense because they are distant and probably have a “lower importance” for updates.
But many other engines that also are able to target mobile platforms don’t face such challenges! Yes, I know Roblox internally is likely VERY fundamentally different to Unity or Unreal Engine, since those engines typically ship separate versions of games for specific target platforms.
But, for comparison in Unreal Engine, while there’s no hard cap on light ranges, the engine uses optimizations like clustered rendering or deferred lighting to ensure lights transition smoothly, even at large distances. Lights are also blended into indirect approximations (like precomputed lighting or irradiance volumes) when they exceed a certain range, preventing abrupt popping or broken visuals.
Would it be possible for Future lighting to adopt a similar hybrid approach? For instance:
Allow pixel lighting to handle dynamic lights within a reasonable range while transitioning distant parts of large lights into a cheaper approximation (e.g., precomputed irradiance or a simplified model like spherical harmonics).
For moving lights, if they are very large, to avoid creating weird visuals, give the chunks that the light is affecting higher priority to ensure they update consistently?
Lastly, does the 60-stud range cap exist solely because of the Light Grid, or are there other constraints preventing larger radiuses in Future? It seems like decoupling Future’s pixel lighting from the Light Grid could help resolve some of these limitations, especially for high-end devices that can handle per-pixel lighting without voxel grid updates. I’ve also wondered why pixel lighting isn’t supported on GLES 3.0/OpenGL Desktop! While I understand GLES 2.0’s limitations, GLES 3.0 is far more capable and is expected to phase out GLES 2.0 in the near future. Is pixel lighting (without shadows) simply too intensive for GLES 3.0, or is there another underlying limitation?
To me this seems very counter intuitive, it reminds me a lot of blenders Eevee renderer where it will warn you in the console that too many lights are in the scene and simply not render any lights above that limit. I feel like the best solution is simply making these limitations for the specific platforms. So for example, here OpenGL ES 2.0/3.0 devices would be far more limited, but powerful consoles and desktops should NOT have the same limitations! But as it has been said before, Roblox tends to want to support features for all their currently supported devices, since some visuals can be very impactful and possibly affect/break the immersion or usage by a game of said feature.
Definitely; I agree. There’s a reason I’m pitching it though: The way I see it is it’s better to have the feature in a bit of an awkward way than not at all, sort of like the Highlights implementation I mentioned earlier. Roblox is very much against locking features to certain platforms/high-end devices, and for many projects these extended light ranges are needed sparingly—not extensively anyways. So it sounds like the right compromise to at least get this feature out the door
Speaking of the voxel grid why do local lights even switch over to to it at a distance, its not like a distant pixel is more costly than a close up one, for the sun/moon this makes sense since it only has shadowmap data for a 500 stud radius around the players camera, (infact if you get the fov just right you can see that shadow maps are only rendered along the viewable area) but local lights are well local and distance doesnt really matter to them they unlike the sun they have a shadowmap for everywhere effected by themselves why must they to abide by the sun/moons 500 stud render radius?
And on the same topic why do other effects degrade over distance: specular highlights, environmentspecularscale, ambient occlusion and dynamic envmaps are all per pixel effects and cost the same for something 0.1 studs infront of you as they do for something 10000 studs away from you, why do they degrade? Shouldn’t the future lighting technology ditch all non per pixel effects excluding the voxel grids sky occlusion since no alternative has been introduced for it.
I appreciate everyone theorizing about potential solutions, but I promise you that if there were any simple or obvious solutions available to us we would’ve implemented them!
No those pixels are not more costly (in terms of lighting), but they are less important (on average), and you’re doing the same calculations on them, which makes them relatively wasteful. On gaming desktops it doesn’t really matter since we have fast dedicated graphics cards and usually aren’t limited by GPU horsepower anyways (at least in Roblox), but on a mobile devices or on integrated graphics it is a significant performance improvement in games that have large worlds, and it may also heavily reduce memory utilization.
Many other game engines also end up cutting off shadows past certain distances because it’s just not worth it to render them that far away, though this can cause some jarring pop-in in an open world game.
Of course there’s a lot more nuance here and definitely ways to improve how this is handled, but in general lowering quality of/disabling visual effects at a further distance is effectively guaranteed to be a performance improvement.
Shadows popping in is expected (you can’t have a shadowmap texture spanning infinity because infinite memory is nonexistant) and effects like particles of course get scaled to a smaller size on screen at distance anyway to the point of being too small to bother rendering.
Though on the fist part yeah sure but that would mean getting close up to things would cause performance drops right?
EDIT: Also why not render lighting at half res? We only need edges to be sharp anyway.
Though - you should look at this more as if it’s the baseline performance of your game. Any automatic optimizations applied overtop of that are effectively a bonus… Or a nightmare, depending on your situation! :3c
This is most notable in actual games, where you’d have hundreds of lights spread out across a wide area, rather than everything all in the same area.
There are some tricks for this to get effectively entire-map shadow view distances with shadowmapping. (Though of course never infinite, but you can’t go to infinity with any rendering technique, and it certainly won’t be fast.)
Roblox actually already does this, kinda. They use a form of shadow cascades which will render further away shadows at a lower visual fidelity. This is most notable if you have shadow softness set to 0 in studio.
Roblox switching to the voxel grid at farther distances may primarily be a consideration of the shadow map size now that I think about it, I noticed that on mobile the lights would cut off significantly sooner than on desktop, even on max graphics, which would make sense since they probably have smaller sizes for a shadow atlas. (Though of course this is just speculation.)
I think i should make it clear im not talking about sun/moon lighting i am talking about local lights i already knew that roblox uses shadow cascades for sun/moon lighting.
My main problem is that local lights(everything not sun/moon) switch over the the voxel grid despite them being the same performance no matter the distance(though due to light range distant lights will effect less pixels and roblox doesnt render lights on pixels they don’t effect) and distant local lights can quite easily continue rendering their shadowmaps there is no reason not to roblox can handle shadows on all active local lights(though they render at significantly a reduced rate).
By “render lighting at half res” i didn’t mean render shadows at half res i litteraly meant rendering per pixel lighting on a half res texture then scaling it onto the full res texure using the depth buffer to reduce light leakage between objects.
I had assumed that this was the case too since I figured that the distance at which lights switch from future to the voxel grid that they would also start using shadow cascades before the shadows pop out completely. But upon looking again, I was certainly wrong.
Yes this is true - but voxel lights still have a lower per-light cost than the per pixel lights do. Though rendering the per pixel lighting at lower resolutions at further distances might be plausible, I think it’s just a matter of how much space is left overall in the shadow atlas and also if doing this is economical from a performance standpoint on lower end devices. (Roblox is quite picky about their use of the depth buffer on mobile devices.)
Though, honestly, it may not really be that much of a concern given how Roblox is actively working on a new version of future lighting tailored for lower end devices, they could just keep the heavier optimizations on that version.
All of this actually does make me wonder what the solution will be for extended light range limits and if render distances will be increased along with that. I guess it’s a solid “we’ll see” at this point.
Glad we came to a conclusion wouldn’t want to bloat the topic too much.
Though i should note that when i was proposing half res light rendering it was for close up objects and far away objects i am more or less trying to push the idea of not discriminating pixels based on their depth and instead discriminating the objects being rendered based on pixels taken up or similar metrics EDIT: and also removing the voxel grid if possible.
I’m just really curious! Is mobile playing a big part here in limiting the options of the engineers? Especially GLES 3.x devices that do not support Metal/Vulkan?
Making a big reply here in hopes this will become a bigger priority.
The light range limits that Roblox has on all light emitters is extremely painful to work with, especially when working on bigger projects.
When the scale of a project increases, suddenly the default ranges on lights becomes a huge bottleneck for lighting games. There are so many work arounds and hoops that degrade from the realism of a game.
The only fix I have been able to work with is extending the light source closer to the area I intend to light it with. This not only messes with the shadows, but if a player were to go behind the limit of the light, they would not be lit up anymore.
If you are going for realism in a game, then the source of light coming from where you actually place it in the world is a big deal. Sometimes, you have to place the light source way farther back than the Roblox range extends.
light range set to 60, light doesn’t even halfway reach
It becomes incredibly obvious where the second source of light is, almost rendering this method useless. The shadows are not true to where the actual source of light is located.
All I am asking is for a change on the light range limits. They just for developers who are trying to keep the source of the light coming from the source.
I personally feel like having larger lights far outweighs any negative consequence vs using more than 1 light source. Currently we have to use a lot of light sources, which is extremely noticeable in Future lighting, making Future only useable in very specific scenarios. I also feel like this should be something that developers actively consider when using longer light ranges (we already do this when switching to Future as it’s arguably more graphically intensive than any other lighting option.)
Also while we’re on the topic of lighting, can we have an option in light sources to make them “flat” / get rid of specular highlights? Specular highlights are really intrusive when trying to fake global illumination / making future look closer to it’s original counterpart where it lights up stuff behind the light source.
This feature would be so cool, since for bulk rooms this limit is so annoying.
The engine limits are of course clear to everyone and all the problems associated with solving these problems, but we can’t still have 60 studs, it’s such a low…
commenting and bumping this post again because Roblox staff would rather encourage us all to ignore this feature request instead of providing us with any sort of answer. no, i want this feature, which is why i commented on it in the first place. this message sent to me in general is stupid and ridiculous, and them deleting my comment is just salt upon wounds
“you replied to a really old thread that hasnt been replied to for a long time, please avoid bumping old posts that are no longer relevant”
last reply: 6 days ago
what a joke.
bumping this thread out of spite + i want this feature too
