Do unions cause server lag?


#1

I have asked this many times and people give me different answers from yes to no to depends on how many. Im honestly a bit confused on this subject. Is it better to leave just a game with 10k parts or union the game down to 5k parts?


#2

I’d recommend using meshes instead.


#3

Unions don’t cause server lag as the server doesn’t have to load the models for the unions, however it causes lag on the client as the client loads the unions, renders them and calculate the physics for the union


#4

so you suggest parts instead of unioning like windows…


#5

The reason why you’re getting mixed answers is because it heavily depends on what you’re doing and how you’re doing it. Some background information on how unions work might be appropriate:

When you create a UnionOperation, Roblox has to do calculations on what the new object should look like geometry wise. The objects you have selected are combined into a new object and Roblox will try to make the UnionOperation as accurate as possible while only generating as few tris/triangles as possible, because the more tris it has, the more data has to be stored and the more rendering calculations are required. Additionally, in order to decompose your UnionOperation, Roblox needs to keep track of which parts a UnionOperation exist out of, so the more parts you merge together, the more memory a UnionOperation takes up. Finally, each UnionOperation has its own unique shape, so Roblox needs to generate collision boxes for each UnionOperation. These shapes can be really expensive, which is why there is the CollisionFidelity option: Default tries to be as accurate as possible, but takes up the most data. Box is literally a box and is therefore really cheap. Hull is like wrapping your UnionOperation in paper and is in between the previous two options in terms of accuracy and performance.

The three things I mentioned: geometry data, child data and collision data all play a role in this lag people talk about:

  • The geometry data affects rendering power, so it could impact your framerate if you have a lot of expensive UnionOperation objects being drawn in your view.
  • The child data clogs up a lot of resources and I think this child data also replicates to clients, so if you have a lot of expensive UnionOperations in terms of memory, you might start to see weak hardware (phones) crash more often.
  • Collision data also clogs up memory, but collision calculations aren’t done until parts start to move around the UnionOperation objects. In this case the server will have to do collision calculations which might take up a long time depending on the complexity and number of UnionOperations. This does not affect framerate but it could make the server less responsive. If your client has physics ownership of those objects however, then your hardware is told to do those calculations. In this case your hardware will be busy doing all these calculations, leaving less time to draw frames which causes frame drops.

Tl;dr
In short, it depends. It’s hard to say how expensive your unions are, but as a rule of thumb try to use as few instances as possible to create your unions. Also check their triangle count every now and then and see if it’s possible to reduce that number by slightly adjusting the shapes. It is also good to reuse your UnionsOperations often because the shape and collision data and such are only downloaded once per unique UnionOperation.


#6

Well thats a hard one, you can union parts but if the player never has to interact with it id recommend unioning it and can collide false. Another thing you should do is if the union has a very simple geometry so like just a bunch of cubes can collide it false and use parts as the collision box and make them invisible.


#7

Did you just mark this as the solution before reading all of it? :eyes:


#8

No I actually read it thank you very much for your help


#9

Anything that includes a tl;dr must be a good answer


#10

Meshes can be just as taxing, if not more.


#11

Meshes also take some time to make and upload


#12

Meshes do not bother with collision generally, so more taxing than unions seems very unlikely.


#13

They do? May not be the most accurate but they still bother with collisions, if not better than unions


#14

Meshes collide using the fidelity you specify. Box, Hull, or Default.

No, unions do not cause server lag.

EDIT: MeshParts**


#15

Are we speaking of the meshes as parented to a brick? As far as I knew they do not affect that brick its collision whatsoever.


#16

The mesh object doesn’t have anything to do with physics. It changes how the object it’s inside renders essentially.

So yep.


#17

Not the type of mesh we are taking about. We are taking about the new MeshParts


#18

Seems convenient to call things by their actual name then. Meshes do not affect performance as badly as unions or meshparts, which is rather relevant to the topic at hand.


#19

It’s impossible to make a broad statement like that.

Mehses are rendering intensive. Collisions are CPU intensive (ignore physx etc).This applies to the visual aspect of MeshParts, and the entire aspect of the Mesh object. However there are also optimizations such as instancing for multiple copies of the same mesh.

I could delve into a bunch of renderspeak but it wouldn’t be useful. Essentially, you should use meshes for objects you cannot model with parts, or for objects you will be using a lot (tree mesh for example).

Personally, I do not use unions in my games because they are generated which means they’re a lot less clean (slower to render, download) than handmade meshes.


#20

Strictly speaking a MeshPart is a Mesh. What you were talking about were ModelMesh