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.
13 Likes
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.
3 Likes
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.
1 Like
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.
1 Like
Looks like you got many different answers. I would suggest trying both. You can always check how much memory it uses through F9.
1 Like
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.
8 Likes
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.
1 Like
It really depends on how your trees are constructed, perhaps include a photo of some?
Meshes will only improve your performance if there is considerable room to optimize the geometry.
For example, if when you say parts you are actually referencing unions, optimizing them as MeshParts will increase performance.
2 Likes
I remember that they showed memory occupy of objects. As I remember, a mesh occupies 42 x a box part occupies. Which means 42 part = 1 mesh.
EDIT: I think that’s the goal in future, not present. Sorry.
1 Like
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.
__
@JuanCupOJuice usually 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.
5 Likes
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.
| Parts | Meshes | ||
|---|---|---|---|
| Memory Usage | 240.19MB | 250.97MB | (+4.9%) |
4 Likes
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
1 Like
This is the tree I’m using. The leaves are made from corner wedges and the trunk is simply a cylinder.
3 Likes
For this example, you should use a mesh. The polygon count would be less, as:
4 corner wedges (4 * 4 = 16) x 5 layers of leaves (16 * 5 = 80) + trunk (80 + 16? = 96). ~ 96 faces
compared to mesh:
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.
2 Likes
I see, maybe I was mistaken. Thanks for explaining it so well, I’ll keep it in mind.
1 Like
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.
Here are the two places I used to run the tests:
Now, the better question is: “Is this worth the time to replace a thousand trees across my game?” That’ll be a fun script to write. 
EDIT: I also studied Unions vs MeshParts in another post check it out here.
15 Likes
Read my above post as to why you shouldn’t count Client-saved objects as if they’re MeshParts.
2 Likes
Yes, there are big memory usage benefits to doing this. This aspect will remain true even on platforms with Part instancing, even if the part trees are made from a bunch of identical parts. Parts (all Instances, in fact) have a non-negligible memory footprint that is just all their properties and has nothing to do with their geometry.
If you’re going to be making hundreds or thousands of copies of something that has any complexity, it should have as few Instances as you can possibly manage. Combining geometry into MeshParts or CSG UnionOperations is usually a good idea whenever the material, texture or decal requirements don’t prevent it.
5 Likes
You could vertex paint the tree so that it would be all one mesh but still take over the colour.
Just export as .FBX and import it into Roblox Studio.
2 Likes
…yeah but I like my trees to have grass leaves and wooden trunks. Vertex painting limits you to smooth plastic or another single material.
2 Likes