So I’ve been working on a project for a little over a week now. This project was running smoothly until I tried to optimize my code. Lets say I have a ship, this ship contains roughly 450 parts. What I’m doing right now to move it is have all the parts anchored, move the engine part, and set each part’s CFrame relative to that engine part (the efficiency of this method surprised me a lot).
Then I tried SetPrimaryPartCFrame. It ran much faster than the previous method… at a cost. After flying around for a minute or so, the parts seem to offset themselves.
Here is what the cockpit for the spaceship looks like after a minute of flying (cracked glass, offset parts on the front and right side of the cockpit as well):
I have attached a demo to display a similar situation (450 parts, anchored, CFrame rotated, etc). Just hit play solo and you’ll see results after around 4 cycles. I made it print the average offset point in the end, but I’m sure you’ll notice it anyway.
We had the same problem in Shiggy.
Since it was only for spinning the preview of an item in our shop, I made it so the original CFrame of the model was saved, and after each spin, the parts resets to their original position to prevent noticable creaks.
Though it’s bad this bug is even present, as seen in this thread.
It’s not really a bug I’d argue. SetPrimaryPartCFrame simply recomputes the local offset/rotation from the PrimaryPart every time you call it and applies this transformation on the new CFrame. The floating point inaccuracies are unavoidable here and they simply stack up if you use this method.
Using welds, you basically store a constant transformation of Part1 from Part0 instead of computing the required transformation from the new CFrame every time you call it, resulting in no loss of accuracy.
(Alternatively you can obviously compute offsets once of each part to the PrimaryPart yourself, and use these cached ones to transform everything yourself, which will also result in no accuracy loss. Welds are probably faster, though.)
