Future Lighting Technology Causes Memory Leak

I’m starting to use the new Future lighting technology for my game, and it looks stunning. However, we’ve noticed that while using it, there is a massive memory leak. The leak is specifically in the render/system section.

We did some testing and here’s what we found:

With ShadowMap technology:

Immediately after joining: render/system: 14.36
After 5 minutes: render/system: 14.41

With Future technology:

Immediately after joining: render/system: 23.61
After 5 minutes: render/system: 49.69

This picture shows that memory in render/system never gets cleared out:

This picture shows that disabling Shadows on lights will return render/system to a normal value and it won’t go up (see the first reply for an explanation):

At one point, render/system got up to 100 mb after only about ~10-15 minutes. At this rate, using Future lighting in my game is not feasible until this issue is addressed. Our findings are consistent with those encountered in this thread: Memory Leak Help? (What is "render/system"?)

I understand that this new technology is probably going to be more heavy on memory than previous technologies, but the gradual buildup of memory usage seems out of place.

Scripts do not seem to be related to the issue at all; as in the thread above, after disabling every script in the game, the issue still persists. Here’s a link to the game where we are encountering this issue:

My system specs:
CPU: Ryzen 7 3700x
GPU: Radeon RX 5700
Memory: 16gb 3200mhz dual channel
OS: Windows 10 version 1909

If you need any more information, please let me know and I’ll do my best to provide it ASAP.

Edit:

See my first reply. This memory leak seems to be linked in some way to the Shadows property of lights.

42 Likes

We have just found some more information that might be of use. In our game, we have a setting called “Enable local light shadows” that goes through all objects tagged as a “light” (this includes PointLights, SpotLights, and SurfaceLights) and toggles the Shadows property of that light. The setting is enabled by default.

If you turn the setting off (therefore setting the Shadows property of every light in the game to false), render/system memory will immediately go down a lot and will not continue increasing. With the setting enabled, render/system memory proceeds to increase unchecked gradually.

As you can see in this short gif, render/system starts at ~58mb. After turning enable local light shadows off, render/system is immediately cut to only 22mb.

https://gyazo.com/5322e64984e9d271027968ef30ef09e7

We have also confirmed this on a newly created, empty place. We placed some lights around the baseplate, and here are the results:

With Shadows on the lights:

Immediately after joining:
21.3

After one minute:
24.5

Without Shadows on the lights:

Immediately after joining:
20.9

After one minute:
20.9

It seems to be that if you’re near a light with Shadows enabled, render/system will increase, but will never get cleared out (even if you move away from the light).

In conclusion, the memory leak seems to be tied to the Shadows property of lights.

5 Likes

Is this actually a memory leak or is the engine just holding onto memory so it doesn’t need to free it only to re-allocate it later? These memory numbers don’t appear exactly mind-bogglingly large or anything.

(e.g. there’s an implementation difference between “memory leak” and just not shedding memory until the point you need to for efficiency’s sake)

5 Likes

In the post, he stated that this number could get extremely large if left running for long enough, and will never go down (even the slightest bit). We observed numbers in the hundreds when we left the game running for over 20-30 minutes. We kept the test time low for our own sanity, but even then, a nearly 36 megabyte increase over 5 minutes is not insignificant.

The point is that while running normally (With ShadowMap technology or Shadows set to false), render/system memory will not go up at all, but with Future and Shadows on, we found render/system will go up at an unreasonable rate and will not go back down.

How are we supposed to know if this is how the engine is supposed to handle memory? It’s better to report this and be wrong than to try to ask ourselves questions we don’t know the answers to. This is a problem for us because it causes unreasonably high memory usage which was not present before and we can fix it by reverting to ShadowMap, but we would like to use the newest technology.

4 Likes

Ok, if it quickly gets into the hundreds of MBs then that’s a good detail to add in the first post. It only mentions “100 mb” at most so far which didn’t seem like a lot, so I asked just in case you could provide more details.

4 Likes

Yeah, it’s definitely a lot. My main concern isn’t so much the memory usage itself because because I would expect a better technology to use more memory. The thing that worries me is the fact that we never observed render/system going down, and it seemed to go up indefinitely.

I’ll make sure to let him know to add this info to his original post. I admit it was worded weirdly.

2 Likes

Pardon the late comment, but this issue hasn’t seemed to have been resolved and is causing me significant concerns, which could hinder other games.

I currently have 189 lights placed around my map, the largest of the bunch being 10x6 studs. Each light has a SurfaceLight with shadows enabled, and a PointLight with shadows disabled. After less than 30 minutes, client memory usage spiked from 392MB to more than 1000MB. Over 700 of which was from ‘render/system’.

There were no local scripts running at this time.

Memory

After doing some research and confirming that disabling future lighting solves the memory problem, I am left to question why this has gone unnoticed by many and if a fix is coming. Has anyone found additional information on this issue?

Edit:
I’ve gone through a bit more experimentation with this issue and found out it only occurs with SpotLights and SurfaceLights; PointLights seem to be completely immune and do not continuously increase memory usage.

I’ve thrown together a small place that clearly demonstrates the issue and what causes it for those who wish to replicate it:
Shadow Leak.rbxl (52.2 KB)

Place explanation

Press the UI on the left-hand side to toggle between the three light types, as well toggling shadows. You will notice the render/system memory usage increase infinitely while either SpotLights or SurfaceLights are enabled while shadows are on. Toggling shadows off instantly releases this additional memory.

PointLights are enabled by default.

Video of place

9 Likes

Hey there, apologies for the late comment as well but this is still a very significant issue to those of us that want Future lighting light object shadows in our game.

Despite searching, I wasn’t aware of this post until a friend pointed it out to me today. I messaged bug support about it 11 days ago. Below is the message I sent, with more hopefully helpful details on the issue:


Light Object Shadows on Future Lighting Causing Memory Leaks

Description
The following lighting and graphics conditions result in a memory leak at Arcade Island: Dev Build:

  • Light objects with shadows enabled
  • Graphics setting 4 or higher (most noticeably max)
  • Future lighting enabled
  • Playing on desktop

Upon entering the game I noticed an immediate and continued spike in memory. After further investigation, deleting all scripts, enabling and disabling post processing effects, changing lighting technologies, and so on, I identified the specific conditions I listed above to the best of my ability.

In the video below I demonstrate the memory rising with some light objects having shadows enabled to suddenly drop after I disable shadows on all light object descendants of the workspace. Later in the video, I also demonstrate how setting graphics at a setting of 4 or higher results in the leak continuing to increase while settings graphics at 3 or lower results in the memory stabilizing. I cannot reproduce the issue on a mobile device, assuming this is due to how graphics settings differ between devices. I was able to precisely reproduce the issue on another desktop client with a friend over a discord call earlier today.

Where
I noticed this while working on Arcade Island Dev Build. After further investigation, I created a simplified reproduction place: [Please direct message me if this file is needed by staff]

When
This bug was first noticed Wednesday, March 31st, 2021 @ ~11:00PM Eastern. This bug happens when the conditions listed above are met 100% of the time.

Video

Reproduction Steps

  1. Open the memory leak file listed above and publish it as a public place.
  2. Play the place using the Roblox Client on desktop.
  3. Set graphics to max.
  4. Wait for the memory to rise. Notice the difference in render/system.
  5. Disable shadows on all light objects in the workspace using the code snippet below in the command bar.
  6. Wait for the memory to fall, this should be very rapid as per the video. Notice the difference in render/system.
for INDEX, DESCENDANT in pairs (workspace:GetDescendants()) do if DESCENDANT:IsA("Light") then DESCENDANT.Shadows = false end end
9 Likes

Yep. The lighting looks really, really good with the new technology. Unfortunately, due to the memory leak, I can’t have it in my game.

As I said in the OP, I do have it as an optional setting for players. We recently made the decision to have this disabled by default, and include a warning because of the memory leak. The setting is nice because memory usage shoots all the way back down after turning the settings off.

I expect memory usage to be higher with Future technology, maybe even climb over time, but this leak is absolutely massive. Leaving it on for a realistic play time of even 45 minutes causes near a gigabyte of excess memory (as @xtntt pointed out) that never goes down until I turn the setting off. When I turn the setting off, all of that excess memory is dumped. Not even moving away from lights will cause it to go down.

I think that this needs to be fixed if Roblox wants developers to be serious about using this new technology.

if it matters, this is the code that controls the ‘setting’ i’ve mentioned. all it does is change all lights to have shadows either enabled or disabled:

	for _, light in pairs(CollectionService:GetTagged("Light")) do
		light.Shadows = newValue
	end

Here’s a longish video of me demonstrating the leak and my setting:

Notice how even after moving away from the lights, memory in render/system continues to rise until I disable the setting which runs the above code. Then all of that memory is dumped. When I re-enable the setting, memory does not go back up because I am not near any lights.

So to clarify, it isn’t necessarily the technology itself, but the Shadows property of light objects that is causing the leak.

6 Likes

I’m dealing with this EXACT same issue. We need future lighting for our game Midnight Vibe because part of the selling point is how nice the graphics look. This memory leak is making it really hard and forcing us to come up with hacky solutions, like forcefully turning of the shadows from lights every few minutes.

I’ve had client memory usage drop from 1100 to 690 mb just by going into our game’s custom settings and switching off the “Light Shadows” settings, which turns off the “Shadows” property from all lights in the game. From just waiting in our game for ten minutes then turning off the setting will show the effects.

Below I have provided two short videos displaying the memory leak on two different machines. I waited for about five minutes and dropped my client memory from 870 mb to 710 mb. My friend toast80e waited at least seven minutes, and she had around the same results. Notice how it doesn’t seem to climb up again if you re-enable Light Shadows.

https://streamable.com/evaoju

https://streamable.com/1mkvyq

For those wondering, here is a code snippet I adapted from my script that can toggle light shadows…

ShadowCache = {}
toggle = false -- this variable changes

for _,v in pairs(workspace:GetDescendants()) do
    if v:IsA("Light") then
        if ShadowCache[v] == nil then 
            ShadowCache[v] = v.Shadows
        end
        if toggle then
            v.Shadows = ShadowCache[v]
        else
            v.Shadows = false
        end
    end
end

This seriously needs a fix ASAP. Future lighting is unusuable in it’s current state.

10 Likes

this was posted november of 2020
has this been fixed?

No, it has not.

2 Likes

greetings, sorry it took a while but this has been fixed. it’ll take some time to ship, i’ll update when the fix is out. thank you!

38 Likes

Oh thank heavens, I’ve had a memory leak issue for the last two weeks and I was unable to work in studio for longer than 20 or so minutes without restarting studio because of it (the memory was going up by around 1-3 MB per second every time I was near any lights with shadows while using Future)

1 Like

Glad this is fixed. Ive had many preformqnce issues with my new game thinking that the problem was my something to do with one of my scripts. But turns out it was the future lighting. My FPS would drop from 60 to about 40 over a few minutes

1 Like

Any news on the fix? This is one of the main barriers for supporting Future lighting and I suspect this could also greatly improve how Future lighting performs in mobile devices if Roblox enables it for those.

9 Likes

Hey there, no urgent rush but is there any chance there is an estimate of when this could be rolled out? I think a lot of us are really excited to be able to use future lighting in our work! :hidere:

2 Likes

Had a user complain about a similar issue, with the game crashing after a set amount of time. Any update on the rollout?

2 Likes

the flag was flipped, the issue should be no more. thank you for the patience!

29 Likes