Does anyone know a suitable limit of parts per map?
I’m working on a simple checkpoint racing game, and I don’t want the loading to be too performance intense.
1 Like
I’m not sure of a hard limit. But if you were to use streaming enabled essentially there wouldn’t be one.
Ofcourse the Hard Hard limit is the amount of memory a given client has available.
While I don’t know any real limits to how many parts can be, I do know that you can push it pretty hard as I have tested in one of my test places.
Anywhere between 4-6k parts should be fine. I’ve made maps for a couple big games and they all told me to keep the part count below 6k
1 Like
This is a very low number to shoot for, and can be quickly debunked by the fact that some of the maps in the 2018 Egg Hunt had more than 10x this. Stick with what others have said: the only “hard limit” is the memory available on the player’s device, which for the iPhone 5s, is around 700mb 
Back at the OP, the best and only way to know for sure is by testing your game in a full server. If you find some players are struggling, find ways to optimize. During development, be sure to keep an eye on memory use, but again as others have said, it isn’t a hard number.
5 Likes
I’d say be relatively efficient with your part numbers. But anything above 50k will start causing large performance issues. With my builds and showcases I like to top it at around 30k and it seems to work fine performance wise. You also have to take in account if you’re using meshes the triangle count, the more triangles the more space it takes up.
Hope this helps!
I just said in my post that there’s no “hard limit” to part count, so please don’t follow my post with a hard limit 
There’s a lot of variables that can change this number - featherweight, use of some materials, and many other variables.
What IS a hard limit is available memory on devices, which as I said for the iPhone 5s, is around 700mb.
I’d go with what @Aotrou is saying, but it’s not specifically part count that causes lag, it’s poly count. More parts means more polys, but more polys doesn’t always mean more parts.
Try to use optimised meshes if possible, and CSG is a mess of extra polys waiting to happen. Parts are pretty well-optimised and they should be okay to use, just don’t go too crazy with them.
1 Like
Granted there’s a lot of misinformation with Parts = poly count when that’s not really the same thing. Parts shouldn’t be seen as if they’re just box MeshParts because they’re not - they’re their own class of instance whose geometry is already known by the client, and thus usually better on performance at a 1:1 comparison - but I want to make clear that that’s not always the case, and is an unrealistic scenario.
Parts are not always more efficient than MeshParts, and MeshParts are not always more efficient than Parts. As I said, there’s a lot of variables to consider, and the best way to know for sure is to test your game in a full server during the development process 
2 Likes
Oh, I was speaking of loading up different maps, not a static one map.
Just to clarify. On top of the client’s available memory being the “hard limit” for how large a given game can be. (Which includes maps).
Part Count is not equal to Poly count. In fact Roblox has already released “instancing” which significantly improves performance on part count. Making parts, textures, and meshparts that are similar in properties to be instanced. Meaning that the group of similar parts are batch rendered.
If you had 10k parts which could be divided in groups of 2,000. Then you have 5 groups of 2,000 parts.
This means there is 5 draw calls. Otherwise you would have 10,000 draw calls. Also note that if you have outlines enabled in lighting that this feature won’t work.
Just because rendering the parts is more performant does not mean this is your bottleneck. If you have 10,000 parts which are unanchored and falling this can significantly slow down physics. Likewise, if you have a handful of parts that are overconstrained, or “freaking out” this can also cause issues. Generally this is why parts fall “asleep” when they haven’t moved for awhile.
Just a heads up, @Aotrou Mesh Parts are about to receive Automatic Level of Detail which will reduce the number of polygons and show a lower quality model the further away you are.
1 Like
Yup I’ve known about this incoming feature for quite some time. While it’ll help significantly for render memory use (GPU), it still will have to load in the full mesh at least once as the player loads (CPU).
But it still will help, and is worth mentioning, so thank you 
1 Like