How Do I Reduce PhysicsParts Memory Usage?

I understand what causes high PhysicsParts memory… so I’ve already optimized it as much as possible, but because I’m using a procedural generation system, it still gets out of control.

The parts are destroyed, yet the PhysicsParts memory never goes down. How do I make this happen? Even when no parts are present the memory usage never goes down… Is there some sort of garbage collection method I need to call?

Try to set can collide properties off on certain parts that you’re very sure that you dont want it to collide.

I do that already, as I mentioned it’s optimized a much as possible.

The server creates chunks as players move through the world. The chunks are made of anchored, noncollidable, parts.

The client then sets each chunk they enter to cancollide, and then disables the collisions of chunks they leave.

As if that wasn’t enough, the server completely destroys chunks that players get a certain distance from.

Despite ALL of this, both the server and client PhysicsParts memory usage just keeps rising until the game is unplayable.

1 Like

For example, when the server starts the server’s PhysicsParts usage is 80 (this is because of some static parts that are not generated)

The client’s usage is 0 (because I use streaming enabled)

Then after about 10 minutes, the server’s usage is up at 300, the client’s is 200ish. This already makes no sense because the server has instanced absolutely 0 physicsparts at this point. Regardless, even if I delete ALL parts, the server’s usage only goes down to 200, and the client’s to about 150. There are 0 parts, yet the memory usage remains stupidly high.

2 Likes

I solved my own issue… sort of.

So for starters I submitted an engine bug report about this. Instancing a part, even if it doesn’t collide and is fully anchored, creates data in PhysicsParts memory. Destroying that part, at most, can remove 2/3rds of that data. Leading to a gradual PhysicsParts memory leak on ALL places since this effect extends to character parts as well.

I fixed it on my procedural generation by instead of having the server create parts in the chunks, it creates CFrame values, named with the name of the asset model. Then the client indexes through all the values near their area and fills them with a set number of assets. So after about 900 assets exist, the client creates NO new parts, and just moves the existing ones to where they should be.

Obviously this only fixes my particular use-case, but for other user’s you’ll need to wait for roblox to fix the issue on their end. As far as I can tell the issue started mid-december, so check your projects and make sure the new leak isn’t destroying your games.

9 Likes

I’m currently building my own chunk system for my new roleplay game. Even if I call Destroy recursively starting at the lowest child in the tree, the PhysicsPart memory does not drop. I am very quickly at over 5 gigabytes which is unacceptable. None of the parts or meshes have an EventConnection to, for example, onClick, onTouch, etc.

local function recursiveDestroy(pInstance)
	if #pInstance:GetChildren() > 0 then
		local children = pInstance:GetChildren()

		for _k, _v in ipairs(children) do
			recursiveDestroy(_v)
		end
	end
    pInstance:Destroy()
end

Does anyone have a solution? I can’t use CDDevelopment’s solution because I copy and delete entire houses from ServerStorage to Workspace.

2 Likes

I have the same issue with my game how did you fix this? I have skills the create parts in the workspace but then are destroyed shortly afterwards however it seems to stay on the servermemory

if i remember correctly, PartCache uses a similar logic which is cool
they create a bunch of parts (you can specify the amount) and then send them to the void (like CFrame(1e9, 1e9, 1e9) or something along those lines)
when used they get put into position. when they get “”“”“destroyed”“”" they instead are just cast into the void again

1 Like