ZSort + Directional Light + Shadows = Memory Leak

[Ma-Shell]

There is a Memory Leak (System::GetMemoryUsage() increases quickly), that appears, when you use a material with z-sort enabled and shadows:

Step-by-Step:

 

- (Create New Project (C++ / LUA))

- Add Camera, Box, Directional Light (other lights don't have the leak!!)

- (LUA:) Add a Script to either one (I used the light) and add the following line:

self.context:DrawText("Memory usage: "..System:GetMemoryUsage(),2,150)

- Add a new material and assign it to the box.

- In the Material-Settings enable Z-Sort (I don't think the other settings matter, but I used: Solid, Cast shadows, Depth Test, Depth Mask)

- Ensure, that the Box is set to cast shadows (dynamic or static) and the directional light casts those shadows (e.g. static + dynamic)

- Start game and watch the Memory rise...

You can also see, that the value will not go as fast, if you untick the Z-sort OR disable shadows

 

I attached a zip, which contains the script, material and map-file, I used. If any other files are needed, I can upload them as well.

[Admin]

You really can't evaluate memory leaks in Lua, because Lua is constantly leaking until it runs a garbage collection call. Memory usage will rise and then periodically get cut back down.

[Ma-Shell]

This is the case when using a different setup, but with the setup as described above, I experienced, there must be something wrong.

When I started the program described above, it startet with a Memory Usage of 2.7 * 10^6 (Byte? Measured using System::GetMemoryUsage()). I monitored the behavior for about 5 Minutes and found that the memory was never decreasing (at least not in a visible manner). In the end I had a Memory Usage of 5.4 * 10^6 (so the memory usage doubled!) still rapidly increasing and never decreasing.

Trying the same thing with the shadows turned off, I found the behaviour I would expect from your description: The Memory Usage always flipped between two constant values (in my case these were 2673842 and 2673926). And this was also the case after five minutes.

 

P.S. Is there a possibility to disable LUA?

[Guppy]

Garbage collection is an expensive operation so it's not done unless needed ( I believe you can force it tho ) this means that there may be a large chunk of unused but reserved memory.

 

And generally speaking leaks tends to grow rather than be static

[Josh]

Really, the only way to test this is in a loop, with no scripts running, or with constant calls to System::CollectGarbage().

 

Sometimes renders or physics updates will "turn on" some functionality that was previously disabled, like an octree node being allocated or something...so those can appear as memory leaks if you only do a simple test. If the application memory constantly grows during a loop and you are calling the garbage collector, then it is a problem.

 

I will look at this, but my guess is it's not an issue.

[Josh]

Z-sort causes a leak. We have a winner!

[Josh]

You are perfectly correct. What was happening was that objects were being added the the light's z-sort list in the shadow render, but the shadow render never makes a call to render sorted objects, since that would be silly. So the list was just getting bigger and bigger since it never got cleared. All better now.