Huh, really? I guess I’ve been hearing wrong then lol
Polygon count is what matters. NOT part count.
The misconception that OP is falling for is that they heard that MeshParts are instanced without hearing that Parts are also instanced - at a much better rate since, as @qqtt991 correctly said, Parts are already part of the Client.
The million dollar question that everyone asks is “well then are MeshParts better than Parts” and the answer is always “it depends” because there are an infinite amount of variables and situations where either could be more efficient, and that’s not even touching the style, theme, or genre of whatever it is.
The only way to know for sure is to test your game with different combinations.
Part count does matter if you have too many of them in your place.
Which eventually levels out to “too many polygons” too.
But from my experience if you have too many instances in one place/spot it will lag.
Part count very much matters.
1600 skyscrapers on the right pic, each one made up of a few unions. 1600 was well under a GB of RAM and not terribly laggy.
Left is 100 skyscrapers made up of parts, but I tried going to 200 and roblox crashed, while I could pan around the 1600 no problem.
If each of the buildings is just a few unions, that can lag the game more I believe, As shown here, Unions causing lag?
1600 unioned skyscrapers and I was able to pan around at ~55FPS. 200 skyscrapers made up of parts and the file could not actually load and went up to 2-3GB. It’s clear in this specific case, unions are better.
As lawyers say far too often, “it depends”.
Yes, as I stated.
I’m not normally this pedantic, but hearing ‘lag’ so many times in this thread is making me sad
Very true, haha.
Okay, I went ahead and did a little science using unions and their optimized MeshPart equivalent.
https://i.gyazo.com/81093d08d8cbb46313e2792dd30507bc.mp4
The left is the MeshPart (314 Triangles), the right is the union (636 Triangles).
The lighting error is caused by ROBLOX’s unioning method and is visible in the in-game union.
From here, the baseplate was covered with the models in an 32 x 16 x 32 grid for a total of 16384 items. Cutscene editor was then used to create a replicateable path both through and around the grid for benchmarking. The total track is 42 seconds in length.
https://i.gyazo.com/a18519afb3301fb2fd59a8f6ec29b915.mp4
Tests were run with only a single instance of ROBLOX Studio open, ‘Performance Stats’ on and OBS recording. The models were anchored, set to cancollide true, and collision fidelity to default.
Meshes | Unions | ||
---|---|---|---|
Memory Usage | 669.5MB | 704.2MB | (-4.9%) |
CPU | 16.67 ms | 16.76 ms | (-0.5%) |
GPU | 3.35 ms | 7.31 ms | (-54.2%) |
File Size | 79.7KB | 163.6KB | (-51.3%) |
Lower is better.
This data makes sense that by optimizing unions as meshes (and therefore reducing the triangle count), you can improve GPU performance.
I didn’t include an FPS count for the tests because I somehow still get a steady 60FPS doing this. Having a lower end computer test this might be for the future.
Also, I did not do a parts only test as this shape is impossible (well impractical) to make out of purely parts.
Interestingly however, I found that performance was even better in the ROBLOX client compared to Studio testing, RAM was a of third what was seen in Studio, and GPU/CPU times fared slightly better as well. It’s 1AM though, so I won’t redo tests there, yet.
My Specs: humblebrag, kidding
i7-3770
24GB RAM
GTX 980
–
For the future:
Changing CollisionFidelity to Hull, and disabling cancollide.
Here are downloads of the two test places if anyone wants to try it themselves:
meshPartPerformance.rbxl (79.7 KB)
unionPerformance.rbxl (163.6 KB)
I’d like to add to that this data is purely focusing on the discussion of unions versus MeshParts.
I highly advice against using MeshParts in place of normal parts as alluded to in OP due to the increased loading times you will experience; let alone the amount of tedious work to undertake such a project would be.
However, if you have a plethora of repeated unions across a build, it might be a consideration to clean them up in Blender. For example, one of my jobs was to take ROBLOX gun models and drop their triangle count by 80%. This worked wonders, especially since this reduced the number of moving parts by a factor of a hundred.
Yes, but unions take more server memory from what I’m aware of…
A simple “Loading Assets” intro to your game would fix the issue and would let the MeshParts load in, yes they do take longer to load it… but would you rather want your game to be slower from Unions taking up more server memory than needed?
Plus, unions have less accurate hitboxes on average
I’m so happy someone proved what I was trying to explain for so long! Unions tend to triangulate meshes more than required and people did not believe me, for whatever reason, my guess it’s their comfort.
I am using only meshparts; and my tip for every single builder is to use unions only when:
- Fixing textures.
(Yeah, that’s the only use.)
And one more thing, as Bixby said. Do not use meshparts for something that can be easily built with parts; meshparts need to be loaded as an different asset, and parts load faster.
So I’d say the go is:
- Build what is big and easily done with parts.
- Build complex assets with low polygon meshparts.
Again, thanks for the detailied report.
If you’re experiencing lag while building in a Team Create, I’d recommend building separately in a single-player place without anything else. I use a template with all of my kit I need to build my models which I can re-use without experiencing lag in the Studio place. After all that I transfer my models into the main place where I cannot build without minor lag or disconnecting. Hope this helped :>
Good post, I’ve done tests myself and the choice is clear. Though one person shouldn’t use all mesh but a healthy mixture of parts and mesh instead of parts and unions.
Even if you mesh a number of parts together on blender the trig count will be the same, meshing unions together will decrease the trigs