Voxel lighting updates are throttled extremely aggressively when there's a single moving part since ThrottleLightGridUpdate3 got enabled

Whenever a single instance is moving near a medium-density area of instances (but not a humanoid? characters don’t seem to influence it), nearby lighting updates get throttled extremely aggressively. I believe this started happening since ThrottleLightGridUpdate3 got enabled (bit more than a month ago by now). Performance is perfectly fine, so this throttling is very unexpected. Finally been able to isolate it down to this root cause.

See the following videos:

Case 1 — There’s a moving part on the left of the screen, and an animating light (brightness) on the right. Note how lighting updates are extremely slow.

Case 2 — The moving part is moved to ReplicatedStorage, out of the workspace. Suddenly lighting updates are visually instant again.

Case 3: — The moving part is back, but I’ve reduced graphics quality to 1. It updates quickly again. Do note that while this is the case for me, many players in my games still have this issue on low graphics quality settings. Intermediate qualities will update lights more quickly too (but 1 is the fastest, 10 the slowest, generally).

Other cases: Looking away from the denser geometry will also cause it to update more quickly again. Or just removing a bunch of it. It also happens in much lower density cases, but the severity is lower in that case.
Moving away from the light slows down updates even more.

The light does not cast shadows.


In all cases I’m running at 60 fps, so this throttling is not at all expected (although even at 15 fps this throttling seems rather overkill when you’re in the lighting chunk yourself…). My own specs: 1080 Ti, Ryzen 1800X, Win 10.

Before ThrottleLightGridUpdate3 got enabled, very large amounts of lights and dynamically updating parts could co-exist at high update rates for both the parts and lights.

All cases use this script to update the moving part and animating light:

local light = workspace.Part.testlight
local pt = workspace.movepart

while true do
	pt.Position = Vector3.new(pt.Position.X, 50 + tick() % 4, pt.Position.Z)
	light.Brightness = (math.sin(tick() * 3) * 0.5 + 0.5) * 5

	game["Run Service"].Heartbeat:Wait()
end

The rest of the game is static geometry for demonstration purposes.

Please reach out in private for a reproduction file with this static geometry.

9 Likes

It’s interesting that they want to throttle the voxel light grid in the first place, considering that the behaviour of it had (until the flag was enabled) been the same since 2013/14 when Dynamic Lighting was introduced. Very concerning - even more so in the unlikely event that it’s a tactic to try and force people to use Future lighting by needlessly breaking things in the voxel lighting model.

4 Likes

Hey all, thanks for raising this issue. I’ve been updating the behavior of the voxel lighting updates to better adapt to the hardware capabilities and performance characteristics of different games. That’s what the throttle flags are for. Some games had a lot of geometry and as result the updates were very expensive, but the engine still scheduled the same number of updates per frame regardless of their cost, making the games run very slow.

With ThrottleLightGridUpdate2 I changed the behavior to predict the time it takes to perform the update and schedule as many as possible while still staying within 16 ms. This got some pushback from developers working on competitive games. These users use fpsunlocker to unlock the framerate, so this was preventing them to achieve the expected frame rates.

With ThrottleLightGridUpdate3 I worked around the problem by limiting the number of updates per frame. I was hoping that would preserve the previous behavior at high frame rates, while still allowing us to throttle down. However, I overlooked that previously we were only capping the geometry updates. I think this should be an easy fix, but I have my hands full right now. Just give me a few days and I’ll try to take care of it asap.

8 Likes

Also, if you have place file that I can use to test the changes and make sure they fix the problem, that would be greatly appreciated. Thanks!

3 Likes

Hello, sorry to appear out of the blue, but it seems that you might have missed this bit:

Have a nice day!

Thanks for looking into this! I’ve sent a reproduction file to you privately.

1 Like

Is it fixed? We are also having problems in our game, as our headlights and neons for cars are visually glitching because of the throttling. No matter if we use Voxel or Shadowmap lighting. Even when the car is driving slow, the lights can be seen “behind” car’s current position.

How about adding a bool property to Light instance to make the light update each frame? @nacasagu

I was wondering about the status of this as well. It’s been affecting moving light sources such as vehicle headlights and spinning alarms for quite a while now in our game.

2 Likes

This issue should now be resolved! If this issue is still occurring, please create a new topic for us to look into.

3 Likes

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.