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

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.

2 Likes

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:

Conditions:

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

https://www.roblox.com/games/2918221866/Triangle-Density-Render-Demo

  • 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

Conclusion:

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.

However

" * 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!

8 Likes

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.

@cloakedyoshi

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.

Conclusion

Hope you use this as reference! Hope this helps!

3 Likes

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:
image
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

3 Likes

This is a perfect answer to all of my worries, thank you very much for the detailed response!
I also never knew how many tris spheres used. :flushed:

Clarifying for your triangle overcrowding example, would this suggest that performance/crashes would mainly occur in dense geometry/triangle areas instead of having a “large” part count overall?

Additionally, for the competition section, where did those numbers come from? I’m curious - they seem right to me, and it’s a great ballpark.

That is indeed true. The distance I’m currently doing is about 5K with an atmosphere object. It seems to work well, hides the geometry, and shows no signs of floating point errors.

1 Like

@cloakedyoshi

I may stand corrected, however if your game sits in the ballpark of 5-10K parts, it’s much better to preload the game once. Roblox can handle 5-10K parts with great ease.

Take a look at these numbers:

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

All these games are playable on mobile and MeepCity itself is designed for mobile with a part count of 13,500 - 14,000.

What to take from this,

Meep City’s use of StreamingEnabled is justified because of the quantity of triangles they’re loading in and out. You really have to consider if your game is heavy enough to justify StreamingEnabled because loading in and out parts like that is very memory taxing. I personally feel you’ll be better off preloading your game as it is very light at the moment and skipping over streaming enabled completely.

With the variables you’ve given us, it’s clear that your coding will create a much higher impact on memory than parts or meshes will

1 Like

I think that’s a good callout. My game isn’t as dense and won’t have nearly as many unique assets as MeepCity - so StreamingEnabled is likely overkill. Wireframe view shows very minimal tris.

My final question - is rendering reliant on the camera’s position and what it can see? Or is it a specific radius around the camera? From your triangle overcrowding example I’m guessing the former.

Using part count to judge performance is kind of inaccurate, as everyone has said. I recommend you export your whole game to an editor like Blender and view your triangle/vertex count there. Because those matter for your actual performance.
A part has 12 triangles and 4 vertices, so you don’t really need to do this if you aren’t using that many meshparts (you can just multiply this number with the amount of parts you have), but just to be sure.
From the top of my head I don’t know the amount of recommended triangles for a game environment, but there are definitely statistics out there. You just generally want to keep that number as low as possible.

@cloakedyoshi

I think there’s a case for both, certain scenarios where the former or the latter would be more intensive or more impactful. I usually test by a case by case basis when it comes to something like this, but I recommend you to wait or search for a definitive answer.

1 Like

A big worry of mine is that this game will experience this feedback through trial by fire. Suddenly seeing the game’s likes/dislikes ratio tank or seeing “devices filtered” a few days in will not be ideal.

I plan on testing it with my small array of devices to ensure it performs as best I can - but once it goes out to Roblox there’ll be a lot of devices I couldn’t test for.

Irrelevant to the point of optimization, however I highly suggest you adopt the standardized shipping process that most ROBLOX games go through now.

Conception
Development
Soft Launch <

  • Heavy limited testing phase with extensive Q.A. (Do this and you’ll avoid a horrible like to dislike ratio)

Official Release

1 Like