It’s disingenuous to assume this is out of laziness or spite moreso than obscure technical details that you as a user have no visibility on. Lets avoid making rude and uninformed assumptions.
7 Likes
Ah, sorry, you’re right. My bad.
2 Likes
can you show a clip of this working? im curious to see how well it works and i dont wanna download that stuff myself lol
2 Likes
here’s a game idea/concept that’s impossible until this is fixed.
Solar systems in which the sun produces its own light
This is already small (humanoid for scale) and it barely reaches the first planet
To get light to reach long enough to make this effect work, you have to shrink the solar system to the point where player characters are bigger than planets
12 Likes
If they removed the limit, I feel like at a larger scale this would be difficult to make this playable performance-wise.
3 Likes
You know, to currently “extend” our light range, we have to use multiple light sources, which isn’t exactly great for performance either.
You get what I’m trying to say?
9 Likes
I guess so. Multiple lights mean multiple attachments and it would be a bad design to load in. However, the lighting system isn’t even that good anyways and nothing is preventing the player from setting their graphics quality to 1.
2 Likes
Speaking of low graphics quality, it also sucks how on low graphics levels often times the lights rendering lags behind, which can make it hard to see in certain cases (and has gotten me killed in some games before due to not being able to see threats).
13 Likes
This is a problem. I’m not sure why most games do not use the FIB technology yet.
3 Likes
I’ve done some small testing with 3 different lights on Roblox Studio using cheat engine to bypass the range clamp present in the editor and I have a lot of stuff to say.
Performance
I loaded a free model city map from the workshop so I’d have some geometry to cast shadows with and have it also be a semi-complex scene for stress testing. This is the performance with one 60 stud light at the default FOV:
60fps | 1.8 ms GPU
This is the performance of one 500 stud light at the default FOV:
59.8fps | 1.9 ms GPU
This is the performance of one 1000 stud light at the default FOV:
59.9fps | 1.7 ms GPU
Ok, so one light has caused no performance loss, let’s test it with multiple lights.
Below we have 3 500 stud lights all with different colours (didn’t bother doing it with other values because changing the light values is a pain with Cheat Engine):
60 fps | 1.7 ms GPU
Ok, no performance loss at all here, so why is Roblox so restrictive with these arguably basic settings most engines (if not all) allow?
I know Roblox likes to focus on mobile platforms, but I believe these optimization choices should come down to the developer and not Roblox, it’s not like every game in Roblox has to also be available on mobile devices.
Even if there’s little performance loss by increasing the light range there are a lot of problems with the lighting in the engine (in my opinion).
The problems
-
Lack of lighting attenuation:
From what I can tell Roblox is using constant attenuation (except for the very end of the light range) for the lighting, and this looks pretty bad because lights don’t behave that way in real life.
In real life lighting loses its power in a quadratic fashion, so the farther away from the light source the dimmer the light gets, you can see this in action in this screenshot from an engine that was used in 2007…
Notice how the light gets dimmer the more we get away from it. -
No control over shadow resolution:
Developers and users have zero control over the shadow resolution in any Roblox game (as far as I’m concerned) and this ends up making lighting a scene up a difficult process, you can notice how it makes the final rendered image look awful with a bigger range simply because the far away objects appear smaller in the shadowmap buffer, therefore they’re projected in a lower quality.
If I decrease the light FOV (therefore increasing the size of everything in the light buffer) we can see sharper shadows but we run into a new problem, since the shadow resolution is so laughably low we run into shadow acne.
Shadow acne happens because of different segments of the shadow map sampling a texel that is inside of the mesh that is casting light on, causing self-shadowing, this can be mitigated (or completely nulled) by implementing a shadow bias at the cost of precision. Roblox implemented that but we also have zero control over that. In the image above you can see both peter-panning and shadow acne happening.
Now let’s see this same effect (without shadow acne) with the 2007 engine (it’s source):
Oh no! Our glowing cat cube casts no shadow, we can fix this by decreasing the depth bias, the shadow blurring, and increasing the shadow resolution:
Now our shadow has more definition compared to the previous 512x512 shadowmap (bumped up to 2048 x 2048). -
Lack of control over game settings:
My last argument for this topic is the lack of setting present in the Roblox client, the players just have a slider to control multiple rendering options, wouldn’t it be better to have an “advanced” tab to allow for more customization? Maybe a player doesn’t like ssao so why can’t that player disable that specifically without disabling other rendering features? Most game engines I’ve seen include both an overall quality setting (low, medium, high, ultra) and individual quality settings, even our old 2007 source engine has that feature (although without simple settings).
Problems with uncapping the light range carelessly
That has been said before in this reply but basically, the lighting engine just isn’t setup to handle that without causing lighting artifacts, it can handle the performance just fine but it will look pretty bad. But it also isn’t a hard thing to change, it’s not like they’ll have to rewrite the entire lighting backend or do super complicated operations to allow for such a change, maybe a bump in quality and giving developers and players more control over graphics settings might make this possible.
Sources:
Shadow Mapping - LearnOpenGL
SourceFilmmaker - Valve Developer Community
Half Life 2: Episode 2 - Valve Developer Community
env_projectedtexture - Valve Developer Community
Shadow Mapping - Wikipedia
59 Likes
I’m thinking that if Roblox were to prebake some of the rendering of the shadows the light range limit could be safely removed since they could modify the shadow bias. This is what some other game engines do, and it seems quite performant.
3 Likes
Yeah, it’s been 5 years and neither staff or devs responded. I won’t be surprised if this will still be ignored.
5 Likes
what i do is chance the global lighting when the character enters a building then set it back to normal when the player leaves.
Can confirm, should be added and as many users have shown via external tools & reverted betas, it doesn’t seem to be any good reason for it not being added, lighting is another one of the worst parts about deving on roblox for me,
stuff like this is part of the reason i try not to touch building as much as possible,
roblox as a creative platform “powering imagination” is simply unusable for actual creative things for me, pure groaning upon creating stuff and having to employ hacky solutions just to get things where could’ve and should’ve looked like in no time at all, and I certainly don’t even try to do all that special things.
7 Likes
Roblox is a complex product and you have no visibility on internal priorities and blockers for new features. Please don’t make up rude assumptions such as this and post them like they’re true. This is obviously a desirable improvement, but there are clearly other things right now either preventing it, or are more important.
@dallasparade this category was opened to replies from non-regulars so you could provide insightful responses that help Roblox prioritize and plan for important new features. Not so you can vandalize topics like a child and ruin your chance of being taken seriously.
12 Likes
Well hey, there’s no excuse for them if they had it in the FiB version. It worked totally fine, so there aren’t any excuses.
You have no idea if this worked “totally fine” in the Roblox client on every single device that Roblox supports. This property was likely unlocked for the sake of proof of concept with no regard for performance or device compatibility.
2 Likes
Updating big areas of voxel lighting is really expensive, it’s probably why there’s a limit.
If this was the case, why has Roblox not implemented some sort of prebaking system already? Car headlights, sure, they can drive around, and they would need to make the lighting run in real-time, but for the majority of lighting it can be prebaked, thus saving lots of performance costs while rendering.
1 Like
You’re right. You’ll probably be happy to know that Roblox already does do this, too. If a light isn’t moving and the parts are not moving, the lighting gets calculated once and stays “baked” until something changes, which is the best of both worlds. For voxel-based lighting modes this means the voxels get written once and stay written, and for future is bright lights this means their shadowmaps don’t get updated either.
The problem is the more area a light covers, the more baking it has to do when the light moves. Radius cubed, so grows pretty wildly. You can test this yourself by making some absolutely massive surface lights and then move small lights near them, it chugs pretty badly because of how big the updated area has to be…
4 Likes