Description
The CPU render time increases dramatically under certain situations, in particular when the player sits in a Seat in a place with many parts. ex, it caused my computer to go from 2-3ms CPU render time to 40ms (or 10ms to 140ms in more complex places) while sitting (until the SeatWeld is disabled or destroyed).
Notes:
- A large number of SurfaceGuis can make the problem worse (that is, they make the lag worse only while sitting)
- A MeshPart/UnionOperation with CollisionFidelity.Default causes much more lag than if it’s set to CollisionFidelity.Box (possibly on part with a regular Part?), regardless of whether CanCollide is true/false
- Seats might not be required (in some tests, I found that walking near to a part that you could walk over triggered the increase in cpu render time for a few frames - but I’m having trouble recreating this)
Microprofiler Reports
microprofile-20200618-102045.html (1.9 MB)
This was captured in a place similar to the Recreation Steps below but with a lesser amount of MeshParts instead of Parts - but with the same result.
microprofile-20200613-211859.zip (2.0 MB)
This microprofiler result came from a place that had thousands of MeshParts, each with multiple SurfaceGuis.
Functions that took longer in microprofiler report
The first microprofiler report shows that the functions taking the huge increase in time are:
- Perform (in the “Render” group)
- which calls Scene
- which calls computeLightingPerform
- which calls occupancyUpdateChunkPerform
The second microprofiler report also showed an increase in these functions:
- Prepare (called before Perform)
- which calls Pass3dAdorn
- which calls RenderWorkspaceAdorns
- which calls StandardAdorns
- which calls GuiLayerCollector:render2dContext hundreds of times
Comment: It may be that these functions are working correctly, but if so, I assume there is some optimization that prevents them from running to this extent every frame. If this is the case, then I would suggest that sitting in a seat seems to break this optimization.
Where
This bug affects live games* and in studio.
*See https://devforum.roblox.com/t/my-game-runs-smoothly-until-you-sit-down-it-causes-a-lag-spike/559481. According to others on that thread, any character sitting down in a place is enough to cause lag for everyone on the server, but I haven’t tested this.
When
At least since May 5, 2020, based on the above link.
Recreation Steps
- Open a new place
- Use the script below to create a Seat and a large number of Parts (but UnionOperations and MeshParts also work - if they use CollisionFidelity.Default, you don’t need as many of them)
- Run the place
- Open up Render stats
- Sit in the seat and observe the CPU render time go up dramatically. If you jump out or disable the SeatWeld, the render time goes back to normal.
Here’s the script for the Command Bar (it’ll create ~65k parts, so lower ‘r’ if you don’t have a powerful computer):
local r = 120
s = Instance.new("Seat")
s.Position = Vector3.new(0, 20.5, 0)
s.Anchored = true
s.Parent = workspace
s = Instance.new("SpawnLocation")
s.Position = Vector3.new(0, 20.5, 5)
s.Anchored = true
s.Parent = workspace
p = Instance.new("Part")
p.Anchored = true
p.CanCollide = true
p.Size = Vector3.new(1.5, 1.5, 1.5)
f = Instance.new("Folder")
f.Name = "Parts"
for z = -r, r, 2 do
for x = -r, r, 2 do
for y = 1, 20, 2 do
local c = p:Clone()
c.Position = Vector3.new(x, y, z)
c.Parent = f
end
end
end
wait()
f.Parent = workspace
What reduces the impact of the bug
- Setting CollisionFidelity of PartOperations and MeshParts to Box instead of Default helps dramatically
- Disabling GlobalShadows and/or switching to Compatibility lighting technology helps (Voxel sometimes helps to a lesser degree)
- Don’t use seats, or disable the Enabled property of any created SeatWeld
