Replicator ProcessPackets very slow

Bug Reports Engine Bugs
#1

In my game players can build machines/vehicles using blocks and they connect together using welds. When a machine with a high part count gets unanchored, the client will slow down to 0fps and eventually crash only on the live game. This bug does not happen in studio. In the microprofiler, Replicator ProcessPackets looks like its the problem. I am on Windows 10. Today was the first time I experienced this bug.

This can be reproduced in my game Astromakers

image
image1911Ă—839 491 KB

3 Likes
#2

Thank you for the report! I don’t see the Duplicate Machine button – could you describe where it is or post a screenshot? Also would it be possible for you to grant me full access? When I join I think I’m in a timed demo mode.

Edit: Got instructions, I was able to repro. We will take a look at this!

3 Likes
#3

Alright, this should be resolved! The main issue is actually not in the Replicator at all. If you zoom out more on the microprofile you’ll see it’s spending most of its time in the updateBroadphase scope, which is part of our collision detection pipeline. A large optimization to the collision detection pipeline was being rolled out, but got reverted on Monday evening because it introduced a regression for some specific cases we didn’t catch earlier. You can read this post to learn more about the optimization, and look at the latest replies for when it’s going to be enabled next: Upcoming Optimization to Collision Detection System - Beta Test on Mac Clients soon

Thanks again for the report, and please let us know if the issue crops up again!

5 Likes
#4

Hey gillern, when you spawn objects into the world for simulation do you weld any parts to those objects far away? With the new Collision Detection pipeline, welding parts to assemblies that are far away will cause some performance issues with the Collision Detection system.

EDIT: Hmm, it doesn’t appear to be as big as I originally though. Something else is going on here.

#5

I wonder if this affects spawning large amounts of Fireball Gfx into a game (20 or 30), which somehow causes a network issue on my Mac with a subsequent error saying something like “Your network connection timed out”. I was repeatedly getting this on Mac, but not my PC or tablet, yesterday. To fix the issue, I had to remove some meshes from the fireball model (which is welded in advance, before parented to the game.Workspace). Taking 2 or 3 meshes out of the model seemed to fix the issue… but the model isn’t as cool as I hoped to use. :frowning:

#6

@gillern when you spawn the object into the world to simulate, how do you do it?

Are you spawning the parts into the world one by one and then parenting them to the workspace one by one? Is there a way you can send me a small repro of what happens when you load the problematic model and start simulating in game?

EDIT:
Are you measuring how long Unanchor takes on the server and then pausing it to let the server step?

#7

This bug stopped happening when the collision detection update was turned off so I cannot debug it anymore.

All the welded parts are close to each other but they are far away from origin

I clone the anchored model for whatever block, parent it to workspace then when the player presses the play button, each part in each model in welded on the server. Every part is then unanchored and I call :SetNetworkOwner(Machine.Owner) for the root part in every block model.

Yes

local LastTick, MaxTick = os.clock(), 5 / 1000 -- 5ms per frame

for _, Object in pairs(self.Objects) do
	local Success, Response = pcall(Object.Unanchor, Object)

	if (os.clock() - LastTick >= MaxTick) then
		RunService.Heartbeat:Wait()

		LastTick = os.clock()
	end
end
#8

I’m going to re-enable this feature in a few weeks so the behavior will return. I believe we will need to revise your strategy for unanchoring. This 5ms timeline is actually generating unnecessary intermediate collision states with the new physics collision pipeline.

Is there a reason why in your models you don’t simply have a few anchored objects per welded assembly? If you simply had a single welded part per assembly, when you unanchor you wouldn’t have to budget like this for performance. It would be extremely fast.

#9

So when the player is building their machine only the root part for each assembly, BasePart.AssemblyRootPart should be anchored? Would constraints still get simulated in this case? Currently when machines with high part counts are unanchored, fps takes a big hit. I don’t want this to be the case while the player is building

#10

Basically you only need one anchored part per rigid assembly. If you have a car with 4 wheels, you need 5 anchored objects. One on the Chassis, and 1 per wheel.