So I’m working on a spicy new map, and it has gotten to the point where there are a ton of trees. Each tree has around 16 parts for the foliage and an additional for the trunk. Currently, there are about 1000 trees so 16 * 1,000 = 16,000 parts total for the foliage.
I don’t think they are causing much lag at the moment, but if they start to in the future, I was wondering if it would be viable to swap those 16 parts per tree to a single mesh so that there would only be 1,000 meshes instead of 16,000 parts.
Its not about the parts, its about the triangles. Mesh or union any colliding surfaces. So it doesnt matter how many there is as long as there is a stable triangle count. I would advise for 16K parts: 150K triangles.
I’d go with parts, why? every mesh has to be loaded from the asset api, that’s a lot of http requests to load them all. Well, more of a combination, meshes should be used for more important things, like weapons, repeated objects like trees could use meshes in my opinion.
Here’s why; as you said meshes are assets that need to be loaded.
Parts as well load; as in position, proprieties, etcetera.
Now; if you build complex shapes with parts; the amount of polygons is never going to be as low as one can build with meshparts.
So my go on this would be; it’s better to have a short-term period of lag on loading assets (This could be somewhat evicted through loading only chunks / using a loading screen.) than having lag on a long-term run.
So; build what it is easily to do and big in terms of sizes with parts, and make the complex shapes with meshparts.
As @Semaphorism said, you should be using meshes for important things, rather than converting everything you can to MeshParts. I also don’t suggest relying on them heavily if you have a lot of mobile users playing your game on devices that may take long to load them, etc.
Use a mixture of both parts and meshes. It also does not matter what the amount of meshes you are using is, what matters is the triangle count. The aim of a mesh is to reduce the triangle count as best as you can, as this helps reduce the loading time of meshes.
Another thing you should consider is if you’re using decals on completely transparent parts. Arseny said this is possibly one of the worst things you could do - I hope that isn’t how your trees work.
If the trees are all very similar, i.e. you can have a handful of meshes and repeat those across the map, you should definitely go with meshes. It is the superior option in that case. If your trees are not at all similar for whatever reason, you should go with loose parts rather than creating a mesh for each tree, the latter is abysmal for performance.
I was told by an experienced developer that parts are better than meshes and meshes are better than unions. Meshes have to be loaded when a user joins so they’re bad for performance.
Studio blocks have around 12 polygons I believe, so that would accumulate to 192000 polygons for the 1000 trees. Unless you can decrease the number of polys on the tree drastically, I’d stick with parts.
Small correction, this is done so incredibly efficiently that I wouldn’t really bother mentioning it. It’s even more efficient if they all have the same properties, known as FeatherWeight, the old term for Part instancing through similar properties. Though you are correct on the last sentence, complex shapes are always better with MeshParts.
I’m not sure where you guys are thinking that Part faces (tris) are the same as MeshParts with faces. Sure rendering is the same system, but Parts are known by the client and should not be considered a MeshPart that has to download its geometry. Basically, don’t consider a Part as just a six sided MeshPart, because that’s not realistic. But as @visualsLord correctly said “complex shapes are always better with MeshParts.”
It’s a different barrel of fish, unless they changed something without my knowledge.
__
@JuanCupOJuiceusually the best method is to get modular with your trees. I’ve made so many different tree models out of four branches, one group of leaves, a root, and a trunk, making each tree instanced. And I can keep making as many different varieties or designs as I want.
If you cut this down to say, two branch types, a trunk, and leaves, then you’re even better because loading in the geometry is still minutely costly.
I use so many MeshParts here for my client who requested them, but these three trees are just an example of using modular branches and leaves, and I can make an infinite set of varieties with these pieces.
This is false, loading a place with 16384 8x8x8 parts (12 tri) and 16384 8x8x8 MeshParts (314 tri, reused from an earlier performance comparison post) resulted in neglible differences in memory usage in my testing.
From experience use meshes for the tree trunk and parts of leafs. Leafs require less detail in my opinion meanwhile the trunk requires more for the branches but again it could be the other way around depending on how you build.
In my opinion to answer part of mesh is mainly decided on if the object your building is either small or large. If the object is fairly small and Roblox can’t support some part sizes go with meshes. If your part is larger then use parts but again there can be some cases where this isn’t true. Do whatever you wish to do
5 faces per layer (bare minimum while retaining same shape) x 5 layers (5 * 5 = 25) plus trunk (as little as 8 faces) (25 + 8 = 33). ~ 33 faces
The mesh is almost a third of the faces of the parts. Additionally, with part instancing a mesh only needs to be loaded once for the client, so more than 200 objects of the same mesh will be loaded at the speed of light for your client. You may also manually resize your mesh parts to create a variance in the trees (extended trunk, shorter leaves, etc.) without affecting the loading.
Each tree would become two MeshParts, one for the trunk, one for the leaves, so you’d have 2000 MeshParts in total. Maybe 10 unique MeshParts for tree diversity.
Based on how simple the models are, I’m not too sure what the performance boost would be; however I’d focus on the potential aesthetic boost that MeshParts could give over the part models. You have a greater freedom in Blender to spice up the leaves so definitely consider them regardless.
Okay, since writing that draft above, I went ahead and ran a benchmark between part trees and some meshed trees I have. Sample size is 6144 trees, 18 parts per tree versus two mesh parts per tree.
Meshes
Parts
File Size
77KB
166KB
(-53.6%)
Memory Usage
228.01MB
456.61MB
(-50.1%)
CPU
16.72ms
16.75ms
(-0.2%)
GPU
2.53ms
2.92ms
(-13.4%)
Lower is better.
Since the trees are so simple, performance benefits in the GPU spectrum aren’t as high as you’d see in other environments.
Summarizing the results, converting to MeshParts would give you greater creative freedom for how the trees look and give a slight boost to GPU performance. The primary benefits would be in file size and memory usage.
So long you aren’t over doing the number of unique MeshParts, loading times shouldn’t be too bad. Anecdotally, it felt that the parts test took longer to load than the mesh parts.
