Yes, that is 133ms for it to make the geometry cluster and yes, that is 12ms on average. And this is on a fast computer, too. I don’t understand why this occurs.
I know that fast clusters are supposed to put less of a load on your CPU by requiring fewer draw calls (I think), but this is ridiculous. 133ms to save <1ms is an issue. I don’t know if this should go in bugs or what.
I’d suggest waiting several frames to see if a cluster-in-consideration is being maintained before clustering.
Having this happen on my game as well.
Did you recently add in CollisionGroups or the new Trail object? Just curious, since that is all I added before I started having this issue.
I did add all team players to their own collision groups and set them to not interact. But I don’t really see how that could be the issue.
That is interesting though, that you have the problem as well, and that it started occurring only after you added collision groups. I feel like it may have been an update, however. I dunno. Hopefully someone important sees this.
This also happens in a game I’m working on. Not related to trails or collision groups as far as I can tell.
Disabled trails and collision groups in my game and I am indeed still seeing it happen. Not seeing any relation here either, was just a hunch.
Hope this gets fixed soon!
I’m not sure if this is related, but recently I have also started noticing parts being updated with a very significant delay compared to what used to happen, which is extremely annoying. Mostly when adding or removing parts. They can take like 5 seconds to appear, which used to be consistently instant about 1-2 weeks ago.
Note the z-fighting, indicating parts did get added, but some old part did not get removed. When some utility (local) parts get removed (exiting terrain mode), the part suddenly disappears.
Similar stuff happens when a ride spawns, it can take like 5 seconds until it is actually visible. Once it’s visible it updates perfectly fine though…
I’ve been experiencing this as well, both frame rate drops caused by updateGeometry and part updates being delayed. Haven’t been able to figure what’s causing it, but it happens quite frequently.
Had these issues before I started using collision groups and trails, so not sure if there’s any relation there.
The clustering system has to update the cluster whenever any visual properties, other than CFrame, change on any part. This has been the case for several years now. We are working on a new system that handles updates much much better, but it will take some time to ship for all types of parts.
In the post by @AxisAngle though, the function takes an abnormal amount of time, and it takes it in the phase that’s usually very quick. This is concerning. I played Phantom Forces and didn’t see anything like this, does this require a special level or setup or something? It would be nice to try to get a standalone repro.
For everybody else who’s posting issues with this, please indicate if they started happening recently - in general we’re aware that some games stress the current clustering system too much which is why we’re working on a new one, but I’m trying to find out if there is a recent regression. Also, please note that for any report to be actionable, we need:
Reports “me too” won’t help us solve this.
Finally, @Den_S - that’s very odd; are you adding and removing the parts in a single burst without any waits() between? Are these parts basic parts, basic parts with special meshes, CSGs or mesh parts? Any chance this is reproducible in a relatively stable fashion? What’s the game?
P.S. Also we’ll ship more granular microprofile markers for this in the next release (in 1.5 weeks) to try to get a better understanding for this.
For anyone who doesn’t know how to do this:
@Nightgaladeld @JParty Would be great if we could get HTML files whitelisted for attachments on the devforums. As mentioned here, microprofiler dumps are really helpful for debugging performance issues that crop up with Client/Studio, and it would make it a lot easier to provide these files to our engineers.
Back before when we did skins on our 20 piece or so MeshPart guns by inserting 6 texture objects in each skinned component, there would be a huge lag whenever we changed the c0 of a weld connecting one of the components, such as the charging handle, which Btw was not textured, to another component, the framer ate on my computer would drop to 20fps or so because of the geometry operations.
We’ve since changed how we do skins when, because of the 0.2 size limit was still a thing, we had to change from unscalable MeshParts to scalable FileMeshes, and it made skins finally playable.
Now, we’re experiencing these problems in the Summer Test Build that we are working on, and we’ve made no changes to the way guns work. We have changed one of the maps to be substantially more detailed, and that is the map I was playing on when I really noticed a lot of lag.
Currently I cannot get any files to you. Sorry.
I see. I can actually sort of reproduce this on PF - I don’t get anywhere near the same level of bad performance as you have on your screenshot, but I do get the similar odd behavior where the part that’s usually fast is kinda slow. Maybe the texture objects take unusually long time to recluster, I’ll take a look at this.
Out of curiosity, why are you using texture objects for gun skins instead of assigning a skin to a meshpart’s TextureId? Do they have to be overlaid over the base gun texture?
We had difficulties trying to create UV maps for gun models built with CSG and reimported as meshes with Blender due to how messy the triangle generation is.
As a result, we decided to go with texture objects, creating a simple repeating camo
texture that works right away and can have its properties changed on the fly for extra customization options to players. We can set transparency settings, tile size, and still have the underlying material of the model show through transparent parts of the texture for cool neon glowing effects.
If we set the texture Id to the meshpart directly, we don’t get to do any of these editing options.
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?
The summer test build Axis mentioned is located here: https://www.roblox.com/games/299659045/Summer-Test-Build#
Thanks! I looked into this a bit closer and found some other issues…
I fixed these two issues, they will probably get released in the release after next since it’s like 8 PM on Friday night 
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: https://www.roblox.com/games/888295789/test – 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:
Here’s @Den_S’s game Theme Park Tycoon 2 which performed even worse:
One second I’ll be touching 60FPS the next I’ll be at 30.
EDIT: Here’s the microprofiler dump for RoBowling (OneDrive), there’s one render frame in there that takes 66ms:
