How many parts is "too many"? When is geometry optimization overkill?

For context - I’m looking to optimize a game to run on all devices without using StreamingEnabled.

  • The game runs well on all devices currently
  • I currently have about 3.6K parts, but I could definitely reach 5-10K parts when finished
  • The game in question uses minimal physics and almost all parts are anchored
  • I use parts sparingly - I’ve already cut down on unnecessary bricks as best as possible
  • I would prefer to not split my game into separate places as teleporting has been very iffy recently

From your experience as a developer, I also pose the following questions:

What part count is when performance noticeably suffers?
  • <5K
  • 5-10K
  • 10-25K
  • 25K+

0 voters

What part count is when crashes frequently occur?
  • <5K
  • 5-10K
  • 10-25K
  • 25K+

0 voters

Does StreamingEnabled alleviate crashing and performance issues?
  • Yes
  • No

0 voters

Looking for advice and insight on this. Given all of the above - do I even need to worry?

1 Like

I don’t think the quantity of parts matter, but the count of triangles being drawn. A mesh can kill more than a simple BasePart can do… if the collision set is precise.

Right. For context then, very minimal meshes and meshparts. Talking mainly primitives (parts, wedges, corner wedges, trusses).

You can try some building techniques to overlap a part over another if they are exactly of the same properties and aligned in any axis. This technique is applicable as long it is not simply destructible. Other than that, depending on density of placement, this will cause lag if very dense.


I tend to stray away from overlapping to avoid z-fighting. I’m also curious if that truly saves geometry - as both parts are still there and are presumably rendered.

I instead try to minimize the # of parts by optimizing my shapes to use the least amount of parts possible without sacrificing the aesthetic. I often avoid brickspam by using BlockMeshes to allow for hidden overlapping.

This is the style I’m building in if it helps - pretty retro:

Nothing here is destructible though.

The technique I’m referring to can be instanciated this way:

  1. Part A and B are aligned along X-axis, both are exactly the same properties in appearance
  2. Part A is resized until it overlaps part B
  3. Part B is deleted

This technique cuts part count by half if you’re building office structures, for instance.

And when I look at the game’s detail from the screenshot, the density of details are fine.

1 Like

I do indeed use that technique by using BlockMeshes. It’s a great one.

Using that technique, I’ve cut this building down from 700 parts to ~200 parts (most are the furniture lol):

How important is density? If I have an entire area out of render distance and hidden with atmosphere or fog - would that help?

I have encountered issues when an area is detailed with 750+ parts in one small location where the rest of the map is heavily less detailed. When I stepped into the 750+ parts area, I started to suffer from frame rate losses. A thumb rule is to make sure the details outside the map is as low as possible and the gameplay-focused areas with more details.

1 Like

All parts that aren’t really needed and seen much by the player, you should set the CanCollide to false just to prevent a little bit of lag since it won’t have to be registered by the Physics Engine.


This is something I adhere to currently. Anything that’s far away and won’t be used is low-detail and low-part. I should’ve been clearer - the area out of render distance would be an area a player would teleport to. It’s not just external scenery.

That counts as a gameplay-focused area as well then. If anything counts as external scenery, you can strip its details down, depending on how significant that scenery prop is to the atmosphere.

I’ve heard about this - would you happen to know how much this helps btw? I don’t think it would sadly apply to what I’m doing, as all parts are needed.

1 Like

Right. I guess what I’m saying is if I separate two gameplay areas by distance - does that help? Does using fog or the atmosphere object to stop rendering of one area while in the other help?

Conversely I could also probably store or destroy the unused gameplay area locally.

Speaking of collisions, they can be laggy if your CollisionFidelity is set to default or precise. If the meshes are very detailed. I assume not.

Hey CloakedYoshi!

Brick Count is Not the End All Be All <

Explanation: When you have an excess of parts, all that happens is it increases the loading time, it doesn’t necessarily decrease player performance. If you follow these conditions you can definitely stretch out the amounts of parts you use in your game:


  • Not crowding your parts in the thousands into one area, this’ll overwork the player’s ability to render. Please try your best to space them out accordingly or heck, even turn on streaming enabled if your game is incredibly part concentrated and large enough where this’d be effective.

Here’s an example of triangles overcrowding. The sphere in the center is highly subsurface and is split 10 times to conform to ROBLOX’s 10k triangle limit. You’ll see how poorly your machine will respond to touch or looking in the direction of the ball.

  • Not using unions to cut down on gross part count, this does the exact opposite of what you think it does.

Exceptions: However if you have an excess of moving parts, then no, that’ll heavily decrease player performance.

Measuring the Competition :

Jailbreak Part Count: 19,000 - 20,000
MadCity Part Count: 25,300 - 25,500
MeepCity Part Count (Mobile Champion): 13,500 - 14,000


You can stretch out the part count as far as you want, there’s a lots of ways to do so and still keeping it performant. However if you’re doing any type of standard build or commission where you don’t want to implement this amount of effort, the 15k - 30k range is optimal.

“When is Geometry Optimization Overkill”

Geometry optimization overkill would eventually set in when either:

  • Your assets are heavily baked in, uninteractable due to obscure hitboxes or are outright nocollide.
  • A refrain of any geometry at all causing builds that lack shape nor style.


" * The game runs well on all devices currently

  • I currently have about 3.6K parts, but I could definitely reach 5-10K parts when finished
  • The game in question uses minimal physics and almost all parts are anchored
  • I use parts sparingly - I’ve already cut down on unnecessary bricks as best as possible
  • I would prefer to not split my game into separate places as teleporting has been very iffy recently"

This description of your game is incredibly light, the biggest of your worries now are definitely how you code your project and memory usage is consumed. If your builds are this accessible and light, your coding is the only genuine cause of performance dips or longer loading times.

Goodluck, hope I helped!


StreamingEnabled, I believe, was helping with extremely large maps from what I remember. Fog doesn’t necessarily help, it does the opposite. Unless you want to visually hide the distant locations.


Triangle Count by Roblox Primitives:

Part: 12 Triangles
Sphere: 432 Triangles
Cylinder: 96 Triangles
Wedge: 10 Triangles

Also to more easily visualize this you should use ROBLOX’s wireframe viewer and look through all your places to check for triangle density and disperse areas with the largest triangle density.


Hope you use this as reference! Hope this helps!


An issue with StreamingEnabled is if you use large parts, it can make parts of the map completely disappear.

Here’s what I’m referring to about distance/atmosphere/fog btw:
Would this help or do nothing?

It would help visually, if you want to keep them away that far. However! There is an issue if you put them waaaaay too far from the 0, 0, 0, you will encounter floating-point errors.

I’m not too sure, this is what is says on the wiki:

Improving Game Performance