Will mesh parts in Replicated Storage automatically load their mesh and so use a significant amount of memory if there is a lot of them, or does it only load once its in Workspace? I’d assumed if a game has a lot of mesh parts that need to be stored (e.g. loads of vehicles) I should put them in server storage to reduce load time and memory usage, but then thought that this might not actually be the case.
It is my understanding that they will replicate to the client when loading the game. They will have less impact on performance since they are not rendered. It’s also important to note that, in theory, multiple mesh parts will not drastically increase memory usage since the mesh is the same between all of them. Memory will only increase to store the new part’s position, colour, velocity, and so forth.
A good question would be whether meshParts even load on the server (besides the metadata) since the server doesn’t render
I’m quite sure that MeshParts would not load in ReplicatedStorage as they are not within the 3D view and thus need not be rendered. You can try passing the MeshPart in a table through ContentProvider:PreloadAsync(t).
Actually, MeshPart and Union geometry is replicated to the clients and stored in memory no matter what, even if it’s in ServerStorage.
Even serverside?
^^^ (yes)
Yeah, the server has the entire game in memory, that includes anything it replicates to the clients like this.
CSGDictionaryService is a service full of a bunch of BinaryStringValues which are replicated like normal objects. These values hold the geometry corresponding to every UnionOperation or MeshPart in your game, and the engine handles figuring out which one of those corresponds to which part when it’s time to render.
So, even if the actual MeshPart or UnionOperation isn’t replicated, the BinaryStringValue holding its geometry (which is the more expensive data, unfortunately) will be replicated to all clients and stored in memory.
This also adds to the initial game download time as well, increasing the wait time before the game is ready to play. Try to have a bunch of small, identical unions/MeshParts so that this works to your advantage, as the geometry will only need to download once for a set of identical Union/MeshParts. Don’t union huge sections of your map, as this works against you and increases data complexity. Use Parts if at all possible (as they are the cheapest resource-wise), and try to use Union/MeshParts for things that will exist multiple times. You can use meshes/unions for unique objects, but only do so sparingly.
FWIW we are working on a plan to change this and stop using CSGDictionaryService but it will take a bit of time