Part count and lag


How badly does part count in a game effect lag and what is a good way to tell if a place has too many parts?


Parts are made up of units called polygons and that’s what causes your game to lag, I’d use a polygon counter plugin to detect what has too much and is causing the lag and you can determine how many parts go into your game, Meshing things general clears up a lot of polygons so if you can do that I recommend it.


Thank you for your help I will be sure to use this advice!


Yeah no problem! :grin:


The problem is if you have too many meshes, that requires more loading time since it has to retrieve all the data to upload/create the meshes in game. (Since you are uploading meshes to Roblox, the game has to get it from the website).


Yeah but once its all loaded your game should process pretty good.


Reality is that having an excessive amount of polygons will hurt your game’s performance, sure, but overall that isn’t the end of it. Every physical object has a collision box and properties such as transparency (which is actually rather taxing on rendering), reflectance, anchored true/false (anchored true is pretty much always better unless special cases), cancollide true/false unless the players is meant to interact with the parts then you might as well set them to cancollide false as that means less surfaces for the physics engine to calculate and so on).

Meshparts, unions and textures are all downloaded and stored in memory (this also means that if you ain’t got no internet connection when working with these assets then you won’t be able to view them in studio), meaning that devices with low memory storage will go RIP if you excessively use unique meshparts, unions and textures. Textures are especially bad so make sure that your textures are as low resolution as you can possibly get away with, AKA no single color 1000x1000 textures. This is a warning, do not use free decals they’re always overkill high res.

Meshparts and unions have a property called “CollisionFidelity”, which governs the collision box of the object. “Default” is an relatively accurate hitbox and should only be used in extreme cases, “Hull” is alright, generates a rough shape of the mesh as a hitbox and of course finally, “Box”, which is just a box (mind expanding, I know I know :^)). If this is confusion to you, simply create a semi-complex union or meshpart and toggle this plugin then swap between the CollisionFidelity modes.

You can avoid that part though if you just set the meshpart or union to cancollide false. But hey, good to know.

One final thing about Meshparts, unions and textures is that these assets have a unique assetID that is specific to that one asset. This means that if you copy the same meshpart, union or texture and repurpose it then the client won’t have to re-load the same asset. And instead download it once, then distribute it to the objects that use it.

Individual color (green, red and blue) is to indicate a unique assetID. The left side shows how you download one asset and then it is distributed to three objects. The right side shows how three assets are downloaded and then distributed to three different objects, this obviously being the less efficient way of doing it if the assets are more or less identical in shape and size. So overall, be careful with not uploading too many unique assetIDs.

ParticleEmitters!!! Oh yes, everyone’s favorite asset spam object. Seriously, if you’re going to use particles emitters, do not use 1000x1000 pixel textures for tiny particles. And don’t have an excessive amount of particles spawning. When creating fires using particle emitters (easiest example I have), then don’t bother having 250 particles spawning to create that “full” flame look. Instead, lower the amount to maybe 15 or 20 and use scale to fill it out. By gradually making the particles smaller and decreasing the size and transparency you can get the same visual look. Something a lot of people overlook is the particle rotation speed, if you set that to -50, 50 or something like it, you can definitely simulate a more “living flame” look. Pro tip!

Overall, regular parts are really performance friendly, so don’t worry about that. They’re more or less as optimized as it gets so you can go with those as much as you like, only when you start to reach 20K or more parts you might start to get issues (assuming that you haven’t spammed 20K parts into a single 0.05 sized cube, changed the transparency, set them all to anchored false and cancollide true. If you have this then all I got to say “you mad man you truly are a rad lad”.

There is a buuuuuuuuuuuuuunch of more stuff but in general the best advice I got for anyone, just don’t be an idiot and excessively overuse assets all over the place. The beauty of a place is not in the tiniest of details and adding too much detail will just make it more difficult to focus on certain areas.

Now I don’t have anymore time and I gotta run so you’ll have to be happy with what I provided above. If you got any further questions feel free to contact me.


I always seem to find games that contain more unions than parts are the ones that lag the most. I think it’s also a combination of scripts that also will lag your game. Not just the bricks.


Wow lol really opened my mind there more