Severe Performance Bug triggered easily with sitting down in a Seat with many parts in the place


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).


  • 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. (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.


This bug affects live games* and in studio.

*See 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.


At least since May 5, 2020, based on the above link.

Recreation Steps

  1. Open a new place
  2. 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)
  3. Run the place
  4. Open up Render stats
  5. 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 ="Seat")
s.Position =, 20.5, 0)
s.Anchored = true
s.Parent = workspace
s ="SpawnLocation")
s.Position =, 20.5, 5)
s.Anchored = true
s.Parent = workspace
p ="Part")
p.Anchored = true
p.CanCollide = true
p.Size =, 1.5, 1.5)
f ="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 =, y, z)
			c.Parent = f
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

I can 100% vouch for this, I have a plane cockpit that heavily relies on surface guis and thus when seated massive lagspikes occur at random in air. Without the surface guis the plane is fine. I don’t understand why Roblox is struggling to display surface guis like this.


This could possibly be the cause of our lag issues, as detailed in this post:

All of the effected games have hundreds of seats and chairs, as we are all school-genre groups.

1 Like

I’m thinking this post is referring to client performance, client fps dropping or just CPU usage spiking over sitting on a seat.

Our issue is related to the entire server becoming unresponsive but no client performance issues.

I’ll consider trying today out, if we lag again, we’ll set all of our seats ingame Disabled state to true. If no luck then I would just believe this is just client performance bug report not the server issue we’re encountering.

1 Like

I was unsure what type of lag they are experiencing since they did not go into detail about the experience.

We should definitely try disabling seats and running a session that way.

Edit: We ran a session with no seats and still experienced lag spikes.

1 Like

This bug is just awful.

I’ve been commissioned to build a parliament building and happened to discover this exact bug. I cannot give this build to my client as it’d be entirely unusable if the players are stuck watching a slideshow from the lag caused by everyone sitting.

The only thing I can do is optimize my game to run really smoothly when not seated and not so smoothly when seated.

1 Like

I brought my seats to a different game and experienced perfect performance. I even added 40K parts and found the game continuing to run perfectly smoothly.

What’s interesting is that because I have a performance overhead available to me, I always get the exact same CPU frame times. It’s as though the lighting engine is told to hold up the entire rendering pipeline before starting the next frame. Even more interesting, though most likely coincidental, is that OP reports CPU time being 40ms, which is exactly how long my CPU times always are.

1 Like

@kleptonaut any possible solution on this issue, im seieng it prop up more now and it is heavily affected when seating near places where neons and point lights arent far from the seat

I am having this same exact issue and it is heavily impacting my game. I made a post here about this issue before I learned that sitting down caused the problem. However, it is not limited to sitting down as tweening objects in a building full of many parts also causes significant FPS drops. Sitting down does cause the FPS to get worse, but it is only one of many things that reduce performance.

The tips you provided to reduce the impact of the bug completely helped (collision fidelity box and compatibility lighting), however, it makes the game look unappealing and makes union collisions completely unreliable.

This bug needs to be looked into ASAP because it is making it impossible for me to continue making my game without insane FPS drops.


@Khanovich Could we get a look at this, the issue is getting worse. From what ive identified if you have even static buildings that don’t move like an airport and your using shadowmap or voxel there will be random big fps drops. Most people reporting definately have the PCs to run these without the sudden drops, It gets worse if your sitting down in a place inside said building like an airport or if your in a vehicle with its cockpit for example having basic surface guis spread out. Even using collisions off and box doesn’t help at all.


Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up here when we have an update for you.


I am in the process of checking over bug reports and following up on some bugs that haven’t received any activity in a while.
Is this issue still occurring or can you confirm that this bug has been resolved?

1 Like

The bug is still present, but it’s been improved: the CPU time spikes up for about a second (ex from 2ms to 10-25ms depending on the Lighting mode) before returning to normal. You can easily test the different modes after following the recreation steps by making a change to the Lighting properties and then disabling and re-enabling the SeatWeld’s Enabled property - each time it is re-enabled, the CPU render time spikes again.

1 Like