Just like CFrame, it takes a lot of processing power to update many Transform properties of Motor6Ds and Bones. This change would enable me (for MadCity) to process at least 20% more bones for the same amount of computation time. This should be an easy and fast change that enables developers to take advantage of the same feature that was implemented for CFrames and give free performance.
46 Likes
Bump, 90% of the work in one of my systems is setting the Transform of bones.
2 Likes
I would also love to see this, and honestly, removing the restriction around BulkMoveTo only working on BaseParts and not with any instance with a CFrame property.
2 Likes
There should also be a BulkMoveMode Enum that prevents any events being fired. At the moment the only options are to FireAllEvents or FireCFrameChanged, there should be a FireNoEvents enum too.
I kind of wonder if the CFrame event is just the most essential event to fire. I’m guessing it hints to the physics engine to update BVH trees and likely many other things aswell.
Unfortunately this won’t do what you’re hoping.
Most of the cost of updating bone Transforms is actually downstream processing which would still need to be done during a bulk update, not the raw Lua reflection cost. That means a “bulk update” function for transforms unfortunately wouldn’t make a measurable difference.
I even prototyped it and confirmed this at one point.
BulkMoveTo is a relatively unique case where most of the speedup is actually thanks to fixing the bad API contract which was set up back in the day on BasePart with too many events firing when a part is moved by scripting its properties.
6 Likes
To confirm, does this reflect over to updating the CFrame property of Bone objects as well? I’m curious on whether pairing it with only FireCFrameChanged would bring non-negligible benefits.
No, Attachments / Bones do not have the same issue, they were designed better from the start. Parts have this issue because they come from the very start of Roblox history.
1 Like
I have a question, does roblox already adresses optimizing old features, or do they have any plans to do so?
1 Like
Lots of optimizations get added to core pieces of architecture like parts+joints, GUI rendering, etc over time. They aren’t just left to sit as they are.
That particular issue with parts is a design issue, not an implementation one: We know exactly how to make it faster (and that’s what BulkMoveTo does!), but we can’t change the behavior of the base properties because that would break some existing developer code.
2 Likes
This is a bit unrelated, but over like the past two days maybe I’ve noticed that Bone Transforms have gone from ~0.002ms per update to >0.01ms per update in a vast majority of cases. I wanted to report this as a bug but I can’t post a bug report.
Are you aware of anything that has changed with this in the engine recently? I created an ocean simulation just a few weeks ago, it was performing at around ~3ms per frame to update the waves and now it’s up over 15ms per frame. But I haven’t made any changes to it for several days, and the last time I did I had the 3ms performance.
Here’s what it was just a few days ago.
Here’s what it is now.
Any simulation in which I have been using Bone transforms is also performing significantly worse than it was two or three days ago unfortunately.
The simulation is entirely client-side.
EDIT: Another member of Roblox staff has reached out about this and is investigating.
6 Likes
This is happening to my project as well. It’s significant.
1 Like
Not sure what your use case is, but it appears as though .Position, .CFrame and .Orientation do not suffer the same performance issues.
That’s to be expected. Transform has a special fast (or it would seem… now slow 
) codepath with minimal invalidation, vs Position / CFrame / Orientation are just hard property updates that invalidate everything.
My project has legacy characters that don’t use mesh skinning (uses part.CFrame), and they don’t have any performance issues. I wonder if I can set .CFrame instead of .Transform as a temporary fix for the performance issues…