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)