Hello, So I have made a big map a I am pretty proud of it. The owner wanted me to convert everything into meshes because of the lag problem. The map is over 20k parts and its been going extremely slow converting everything. I’ve tried mass exporting into blender and back, but I can’t get colors and textures plus its too many voxels. Does anyone know any fast methods to convert all the parts to meshes?
Perhaps this will help you a bit.
You friggin saved my life tyyyyyyyyyyyy, it worked so much.
Do you have a saved version from before you used the plugin? I’d be very interested to see the memory use differences.
20k Parts is not a lot of memory use, and changing those to MeshParts theoretically shouldn’t make it better, and in some cases could make it worse for performance. I could be wrong though, which is why I’d like to see proof
After using the plugin, the tri count didn’t decrease at all. It just stayed the same.
@iGottic help us here!
Wow.
Tri count is not and never has been the standard for how much memory use is used in a game. There’s at least 10 other factors that add to memory use, and looking at any one factor individually can lead anyone astray when trying to fix performance issues
It’s also worth noting that Part geometry (in all shapes) is known by the client. MeshParts and Unions have to be downloaded. This can affect initial load times and is always a balancing act - remember that load times that are too long will turn away players just as much as poorly performing games!
I go into a bit more detail about the memory use impacts in my RDC talk if you want more info. I focus mostly on visual impact (Parts, MeshParts, Textures, etc) - I don’t touch code impact.
If you head to the Performance Builder DevForum page I have some benchmarks.
It makes the biggest difference when you need to do active geometry recalculation, such as moving or spawning instances.
@iGottic It feels like this plugin (whether it works as intended or not), seems like it’s still not a great fit for a static map as MageOnix is asking for.
If you really think it’s great for all map situations, I really recommend you to make a map with two versions, one using your plugin, and one not using your plugin, for people to compare. I’m more interested in Memory Use differences, which I don’t think your plugin improves in any way.
If your plugin does make a difference in this regard, I’d have no problem recommending it going forwards. But the burden of proof is on you, not me.
@MageOnix ensure that your client understands that converting maps to MeshParts doesn’t directly cut down on performance issues by itself. You should consult your map’s Memory Usage in your Dev Console to see what is actually the problem. I doubt 20k Parts is causing that many issues unless there’s an exceptional situation.
Oh, the map, yes, it isn’t that much, but that included with the terrain, and other parts in the main game causes performance issues. Though I have done it per my client’s request. I do believe it is the massive terrain and lighting use that accounts to problems.
Do you have a saved version from before you used the plugin? I’d be very interested to see the memory use differences.
Unfortunately I do not have a saved version, but I do have some progress versions with a bit less parts that you can try out if my client allows distribution of the map.
That has been done, actually ^v^
In both the replies of the post and on my own games, I have done this (with a reported 20+ FPS for some users).
Here is an example, of GPU usage being cut down a ton by using Meshes on a static map in it’s own standalone place.
With Parts:
With Meshes:
Render frames were similar as the camera was static.
CPU and Memory usage will not be as affected, if at all, unless you are not doing static maps.
I would much rather have a link to these games so I can see for myself.
This makes me less hopeful, and definitely something you need to include as a big asterisk in your explanations. Not making a difference in Memory Usage is very important to mention lest people get the wrong idea and apply your plugin as a fix-all solution.
Alright! I think the best example would be Swift Hightail.
Before, with parts, the game ran at about 30-40 FPS. Now, it runs at whatever framerate my Roblox is set to, normally 144+ FPS.
If you would like the direct comparison between two basic maps, you can find examples in the performant builder replies. I’d rather not get too involved again though to avoid repeating myself haha.