Meshparts with default CollisionFidelity are much more laggy than they were before today

Bug description:
Default CollisionFidelity when resizing meshparts now results in massive lag that can causes player to crash. Medium-sized(50x50x50) default collision fidelity meshparts now cause massive lag from almost anything (resizing, colliding, etc) and they do not have to be unanchored or noncancollide. Previously, this did not cause any severe lag.

How often does the bug happen?
This bug happens all of the time but it is more noticeable to players on a lower end PC. Also for us specifically, none of our meshparts had a .touched event connected to them.

When did this bug start happening?
We received our first report about this bug 4 hours ago (6:27 PM PST). To be clear, we have not updated our game for over 2 weeks and suddenly some tools would lag players so badly that everyone in the server would crash.

NOTE: We have since fixed this by changing the CollisionFidelity of most MeshParts to Box, but we think this problem should be brought up either way

Repro example:

   local wave = game.ReplicatedStorage.Ring:Clone()
wave.Anchored, wave.CanCollide = true, false
wave.BrickColor = BrickColor.new("White")
wave.Size =  Vector3.new(1,1,1)
wave.CFrame = CFrame.new() * CFrame.Angles(math.rad(90), 0, 0)
wave.Parent = workspace

local t = tick()
while (tick()-t) < 1.5 do
    local a = math.min(tick() - t, 1)
    wave.Size = Vector3.new(50, 50, 7.5) * a
    wait(0.5) 
end
wave:Destroy()

To test this bug, please download the following meshpart of a ring and place it in ReplicatedStorage and then run the code above to see the level of lag I am referring to here in this post.
ring.rbxm (6.5 KB)

4 Likes

I enabled something that is supposed to optimize bounding boxes for CSGs. Testing now.

4 Likes

Rolled back what was causing this problem. Will try update once I fix this bug. Thank you for report.

2 Likes