We have recently found an issue relating to fastcluster rebuilds for our in-game death effect that should have been fixed in January of this year when they released a change that stopped fastcluster rebuilds on color/transparency changes. Since this is in an already-published game that I work on, I can not provide the full rbxl file, but I can provide microprofiles and code snippets. I have been able to diagnose the core cause of the fastcluster updates down to a simple color and transparency tween that happens on every basepart under a player character when they die (as a death effect). We also have extra stuff to set the material and other physical properties, which I do think setting the material also causes these fastcluster updates unfortunately. I have attached the code snippet + microprofile below for debugging, and if you need to know anything else (or want to enable extra telemetry to figure out the core issue) please let me know. The game specified is 15646364136.
The death effect stripped down to specifically a color/transparency tween:
Tweening a basic humanoid model manually, only color and transparency (yes i deleted all extra meshes after this video and it still happened):
Code snippet of the death effect stripped down to the tween only:
microprofile-20260829-155118.zip (7.1 MB)
Easy way to replicate the issue:
Insert a default humanoid model and the code below
local h = workspace.HumanoidRig
for i,v in h:QueryDescendants("BasePart") do
local t = game:GetService("TweenService"):Create(v,TweenInfo.new(1,Enum.EasingStyle.Sine,Enum.EasingDirection.InOut,10,true),{Color = Color3.new(1,1,1),Transparency = 1})
t:Play()
end
Expected behavior
Fastcluster updates should no longer happen on color/transparency changes within humanoids.
A private message is associated with this bug report
4 Likes
Thanks for the detailed report, the minimal repro made this quick to confirm. I’ve reproduced it and can explain what you’re seeing.
Why the January change doesn’t fully cover this
That optimization removed rebuilds for Color and Transparency, but for Transparency it only holds while the value stays strictly between 0 and 1. Crossing either endpoint, in either direction, still requires an update:
- 0: fully opaque
- 1: fully invisible
Your Color tween is genuinely free. The Transparency tween from 0 to 1 crosses both endpoints: once when it leaves 0 as the fade starts, and once when it reaches 1 as it ends. So you get two updates per part rather than none.
Workaround that helps: end the fade just short of 1
Ending at 0.99 instead of 1 removes the second crossing and roughly halves the cost. The part is visually indistinguishable at that value. You’ll want to destroy the character afterwards rather than leaving it sitting at 0.99, since it does still render.
Workaround that does not work: starting just above 0
Starting at 0.01 instead of 0 would also remove a crossing, and I want to save you the experiment: it keeps the part permanently in the transparent rendering pass, which has depth writes disabled. Parts of a character that intersect each other then don’t resolve depth correctly and you get visible sorting artifacts even while the character looks fully opaque. Please keep starting from exactly 0.
1 Like
Thank you for the insight on the transparency stuff, I will try and implement it for some of our humanoid rigs. However, color being “free” is not true. I trimmed the tween to color-only on a basic rig and it still forces fastcluster updates every frame of the tween. Maybe I did not interpret the reply correctly but I will just post what i got anyways:
The color tween causing fastcluster updates seems like a bug, but the transparency issue you described seems legit and my fault. I did also notice that fastcluster updates occur on EVERY tween frame regardless of it being a color/transparency only tween. To me it seems like the january update was either reverted or broken from a recent change because I noticed a few months ago that this was not happening.
To reply to this, I recently asked a player to send me a microprofile of the frame spikes they are mentioning. Amazingly, they are getting 2000+ millisecond spikes on the fastcluster updates every time an enemy is killed (even after i completely removed the tweening from the death effect). Here it is so it can be properly debugged:
microprofile-20260902-020324.zip (1.9 MB)
My earlier reply was too broad on color. It is not free when the part’s appearance is baked into the character’s combined texture, and that is the default for standard avatars, blocky and mesh alike. Changing color on one of those rebuilds that texture and the character’s geometry with it. The exceptions are body parts with a SurfaceAppearance, which is what skinned avatars use, or with a non plastic Material. That is a gap on our side, not something you can work around.
How often does that color tween run, and on how many characters at once? I want to know what this is actually costing you before we decide how to prioritise it.
The 2 second spikes are a separate problem, not caused by the tween, which is why removing it did not help.
The whole 2.47 seconds goes into precomputing UVs. A plain spawn would cost the same. It is far slower (1000x) than it should be and I cannot explain that from the code, so it needs a real investigation.
Can you share the enemy model, or the place? That lets us profile those meshes directly.
To answer your first question, the color tween happens a single time for every BasePart when a player or enemy character dies. It is never ran more than once per character, but it does happen after a material change to Neon. No body parts have surfaceappearances in them, but we do have clothing and weapon assets with SA. Usually, this death effect will only ever happen on one character at a single time, and could possibly happen on 2-4 if you are playing with groups of 5 and kill multiple enemies at once.
All enemy models are barebones R6 rigs with mesh clothing/weapons parented under them with welds (the weapons are welded to a part that utilizes a motor6d for animations). The place is Absolvement.
From what I am understanding here, the lag spike may have to do with deleting surfaceappearances/decals within parts and meshparts since it is computing a lot of UVs, though I am not sure why it is abnormally high compared to before. Thanks for taking the time to investigate though
