Ok, I looked into this a bit. There are two issues with PF that I see:
We have one bug that we actually already have a fix for where adding or removing models with humanoids (including players) triggers a reclustering on every object in the world. This will be fixed in the next release.
One other thing that happens frequently is that there’s some script that seems to flip Transparency between 0 and 1 on objects like this: “Workspace.PlayerName.MP412.REX.Slot2”. This only causes reclustering on the model of this player, but it’s still not ideal. Not sure if there’s another way to do whatever it is you’re doing here or if this just needs the new clustering system.
I’m still not sure why updateGeometry takes so much time in your case though. You mentioned it’s a new map in progress - any chance you have a link to a place you can give me access to?
Finally, the actual issue in PF test build (aside from sound loading stalling very frequently) looks like it’s allocating a large chunk of VRAM for the cluster (around 5 MB on my build - my build has a memory optimization that’s not shipped yet so that’s a bit more on production build), and for whatever reason AMD driver decides it needs ~50ms to allocate a buffer this large. I haven’t figured out why this is happening, but due to the size of the cluster I suspect it has many mesh parts/CSG parts, and something changes in that cluster, like maybe a corpse is added there or something like this.
Overall, we will ship some clustering performance improvements over the next two builds, but the real fix is the new clustering system which is close to getting released for Mesh/CSG parts, so there’s hope; enabling it on that summer test build place seems to completely eliminate the spikes other than sound loading.
The terrain is updated without any yielding.
I did now figure out with your waiting hint that the tool its utility parts (the height markers etc.), whose CFrames etc were set every Heartbeat, were causing it to not update the terrain parts. Removing those Heartbeat updates will make these terrain updates instant…
The terrain is all parts in this case. The utility parts are sphere parts.
Weird thing is that it’s not easy to reproduce: it happens consistently in the loaded game above, but it’s definitely depending on something else (maybe a lot of meshes in memory?). When I remove things, the issue disappears at some point. If I remove things, but keep enough things to make the issue occur, then save + load that same scenario, the issue is suddenly gone too.
You can observe the behavior here: TPT2 Console test - Roblox – chat !qfl Den_S 1 5 to load the game where I can make it happen all the time.
I don’t know how related this is, but I’ve been getting constant lag spikes for maybe just over a month now. It seems to happen in different games and I’m the only person I’ve talked to with the issue. My hardware shouldn’t be an issue I have a laptop with Windows 10, GTX 1050TI, i7-7700HQ and 8Gb ram.
The more players in the game, the worse it seems to get.
Here’s my game RoBowling, this has had no new features like trials or collision groups added to it, I’ve optimised geometry around the game as much as possible:
Yep. Phantom Forces has had this problem for about a year. But not this badly until recently.
Good news is that there is a brand new system coming out soon that will fix this.
We don’t know what it is, but whenever SettingsHub is run, it takes about 30ms on my computer, and it happens quite frequently. We’re talking 5 times per second for some period of time from 1 second to 5 seconds.
Came here to say that settings hub is also taking up ~25ms of time in my game also. It looks like its trying to change a bunch of guis, its inconsistently showing up though.
updateWaitingParts triggers when there’s a CSG/MeshPart/SpecialMesh asset that finishes loading, and updates the rendering representation for that part from the loaded asset.
The stall you’re getting is in the same place @AxisAngle is getting it, which - if my results are similar - is due to driver/Windows taking forever to fulfill the VRAM allocation request. I haven’t really seen this particular problem before so I suspect it’s a Windows update or a driver update.
The player join/leave leading to complete rebuild of rendering geometry should be live right now (the site is experiencing some other unrelated issues though…)
Next week we’ll ship some other optimizations for updateGeometry, and also better microprofile diagnostics.
And also the new system is shipping for MeshPart/CSGs soon (actually soon, not soon™).
@AxisAngle do you still see the lag with SettingsHub in your test place? Have been trying to repro today, haven’t seen it yet though. Running a 2015 MacBook Pro, I might jump into windows and see if that has the problem.
When you say frequently, should this happen throughout my play session? Or just at the start?
