Large spikes caused by unexpected updateInvalidatedFastClusters

System Information
Ryzen 7 5800X
RTX 3080
32 GB of ram
Windows 11

Reproduction
To trigger a updateInvalidatedFastClusters spike, simply parent a part to the Workspace.

while true do
	local part = Instance.new("Part")
	part.Parent = workspace

	task.wait(0.6)
end

These spikes won’t show up on an empty baseplate though. I’ve included a place file privately that can show the spikes as it seems to only happen on maps with some detail. The place file has no code running (other than the script that parents parts) and has no humanoids.

According to the docs, updateInvalidatedFastClusters is correlated with humanoids, however, the repro place has no humanoids.

A private message is associated with this bug report

1 Like

Hello and thank you for reaching out. The reason this happens is that when you parent a part to the workspace, it creates a “virtual” skeleton with the workspace being the root. This will cause slow downs for sure, and is the current expected behavior. Our recommendation is to always place parts under a an empty model or a folder created below the workspace in the tree. That will avoid such spikes when directly parenting to the workspace.

Please let us know if you have additional questions, or if we can provide further assistance.

Thank you again for your patience and support and for reaching it with issues.

I tried parenting the part to a model and a folder and I’m still seeing the same spikes.
image

1 Like

Do you mind sharing your latest rbxl file so we can investigate?

[EDIT]

Instead of putting the Parts under Models, put all the skinned MeshParts in your Workspace under Models:

local function addSkinMeshModels(parent)
	children = parent:GetChildren()
	for _, child in children do
		if child:isA("MeshPart") then
			if child.HasSkinnedMesh then
				print(child.Name)
				model = Instance.new("Model")
				model.Name = child.Name
				model.Parent = parent
				child.Parent = model
				continue
			end
		end
		if child:isA("Model") then
			continue
		end
		addSkinMeshModels(child)
	end
end

local workspace = game:GetService("Workspace")
addSkinMeshModels(workspace)

Do folders work for this purpose as well? Also curious, why is this expected behavior? What is this virtual skeleton?

This is highly unexpected honestly, I wish Studio would offer hints to avoid gotchas like this, putting things directly into workspace is an extremely common practice.

[EDIT]

This is not your fault, there are several interacting engine bugs at play here:

The “Tall grass” MeshParts in your Workspace are skinned. So, the engine searches for bones to build a skeleton for them, and renders them using FastClusters. For typical skinned characters, the skeleton search is limited to the hierarchy beneath the character’s Model. Because these skinned meshes aren’t under any models, the engine searches the entire Workspace for possible bones. Additionally, when new Parts are added, the engine considers them potential new bones, so it re-does the skeleton search, and rebuilds the FastClusters. The skeleton search is fast, but the FastCluster rebuild is slow, especially for skinned meshes, which causes the spikes you are seeing.

All this work the engine is doing is obviously unnecessary and inefficient. We are aware of this and are actively working to make it faster and more efficient on several fronts. We have an optimization in progress that reduces the FastCluster rebuild times significantly. We are also aware that the “Workspace skeleton” is inefficient and are considering changes to improve that as well. Thanks for your patience with this!

7 Likes

No, Folders do not serve the same purpose as Models and won’t help here.

1 Like

Why is the workspace considered a valid skeleton root at all? Seems like an easy quick exit to check if the root is the workspace, this should never work.

Also, the “fix” I am suggesting is just a temporary workaround, we are planning to fix this in the engine so you will not have to worry about it in the future.

1 Like

This is also a bug. Unfortunately this one is tricky to fix, because changing it has the potential to break games that are currently using skinning in the Workspace without Models. We do plan to fix it, we just have to do it carefully, which may take some time.

3 Likes

Gotcha, that’s fair. Games doing this are foolish though, this is on par with putting humanoids in the workspace…

2 Likes

Another compounding issue is there is currently no visual indication as to which MeshParts contain skinning data. There used to be a special icon for skinned MeshParts, but it was accidentally removed. We are working to restore that as well.

5 Likes

I’ve updated the script to only parent skinned MeshParts under Models. It will also tell you which MeshParts are skinned, in this case it is the “Tall grass” meshes.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.