Brickshift issue for rotated models

[BritishTrainspotting (BritishTrainspotter)]

When moving models EITHER by the move tools or the position property, you will notice that their parts no longer maintain their relative positions to each-other. Critically, brick-shift seems to be a gradual step based on how many times you move a model, meaning that if you create a curve out of those models (or just duplicate them a bunch in a row) then brickshift on each new model is increasingly worse (if you duplicate from the newest one, but using the same model to duplicate from only results in all models having one “step” of brickshift)

Replication Steps:

In this example (my latest experience with this bug) I am creating a curved railway (train) platform, which is done by duplicating a platform model, and changing its position and orientation to match each track segment (then moving it to the side).
If I duplicate the newest model along as shown in this image below, the brick shift is intensified with each duplication (I am moving them using the position property):

And here’s a comparison with the start and end platforms from when I do that:

You can see that the end platform has developed some gaps and offsets between the parts of the platform model. This should not happen.

The key to this bug, and to know its an issue with moving objects and not their distance from the origin (the original platform model has no gaps) is that if I duplicate all of them from the start model, the brick shift is extremely reduced:

Start:

End:

As for how you can replicate this, its likely far easier.
Setup a test with two models containing an assortment of parts of various sizes that are touching each-other (no gaps) side-by-side. Start duplicating them in a row:

• One row you will duplicate the latest duplicate (i.e. what is selected, the fastest method)
• The other row you duplicate from the original / start model (a lot of going back and forth)
  You should see that the row where the duplicate is duplicated results in a LOT more brick-shift down the row than when duplicating from the original.
• If you want to see how Studio Build Suite does not have this problem, do two more rows using the same methods as the first two, but exclusively moving using SBS’s move tools.

Summary

Brickshift from moving objects should not be a problem in 2025 if Roblox wants to even remotely hold up against other engines and game development tools. While I understand that brickshift as a result of precision loss the further away parts are from the origin cannot be solved, there should be no brickshift caused when moving parts.

I would massively appreciate if other developers can share their examples of brickshift in the replies to show just how significantly this affects creators across the platform. For me, it is incredibly frustrating that I not only have to actively remember this issue exists, but to perform the complicated workarounds to reduce its effect (duplicating from the master model rather instead of duplicating from the nearby duplicate, which takes FOREVER).

If how I’ve phrased this bug report seems amiss in any areas, please let me know and I’ll try to improve it. Any questions please ask!

A private message is associated with this bug report

[tnavarts]

These are curved sections so all the positions are off-grid and will accumulate some amount of floating point error as you work far from the origin. The reason you don’t see this all the time is that both SBS and the DraggerFramework use PivotTo which caches offsets between parts in a model during a given session to avoid the parts drifting during repeated moves.

But that offset cache doesn’t carry over between clones or through save/reload cycles, which is why you see more error when cloning.

I could make a way for it to carry over between clones, but I definitely can’t make it carry over between save/load cycles because that would cause a considerable increase to the size of places, like, we’re talking well into the double digit percentages.

1. Do you think making it carry over between clones alone is useful (even though that will stop helping as soon as you close the place).

2. You mention SBS. Help me understand, are you saying that SBS can actually handle a case like this one better? I would not expect SBS to be able to do any better in this case.

[BritishTrainspotting (BritishTrainspotter)]

I understand the reason. I would really like if the offset was cached during a session, and also I’d really like if you allowed us to retain that offset cache by it being saved on our local system (automatically) alongside saving or publishing to Roblox. Could that be developed? Or perhaps allow us to set an asset as the original so that duplicates of it can use the original (which has an orientation that is a multiple of 90 degrees) as a reference for the offset?

[Ed_Win5000]

There may be an obvious answer to this, but wouldn’t it be possible to store CFrames in local space for objects within a model (this is presumably roughly what you have cached). This would obviously not be backwards compatible, but would allow greater numerical precision and cause minimal extra data use (just a flag to mark that this was the case). These local space CFrames could be converted back into the existing world space CFrames fairly trivially at load time.

[tnavarts]

I’ve actually tried to do this. The issue is that the conversions aren’t just at load / save time. When you weld a part in a model to something not in the model it has to be in world space again as part of the welded assembly. Then when you destroy the weld it has to once again become in local space. In addition to other transitions like enabling / disabling the joints, etc.

Managing these state transitions in a consistent way makes it very tricky to get a more “native” local space construct.

[tnavarts]

By the way, I’m still interested in how SBS compares. Do you consistently see SBS doing better? Any detail to what situations it does or doesn’t do better in?

Because I consider this more of a feature request than a bug. Outside of that aspect: If SBS is doing better then there probably is a bug to fix.

[BritishTrainspotting (BritishTrainspotter)]

I thought that SBS had fixed it, but I tried it and it doesn’t seem to. I think I was mistaking it for a similar historical issue, not sure. Edited the post to represent that.

[tnavarts]

Closing this because there’s no directly actionable bug here, though we’re certainly aware that some better way to deal with floating point error for what are supposed to be cohesive models is a pain point.

[BritishTrainspotting (BritishTrainspotter)]

Are there still plans to work on a solution for this issue? If so I’d like to be kept upto date if possible please

[tnavarts]

I can’t promise anything in the short term.

What I can say is that I’m the person most responsible for that area and always looking out for opportunities to make it better.

In the interim, the engine’s native “answer” to this is to unanchor all but the root part and use joints. If you join your model with Welds those are the way to represent local space relationships that will be preserved no matter how far you are from the origin. Obviously that doesn’t come for free, but it is a solution that’s available now.

If you want to track the problem a thread breaking down the various floating point pains in Feature Requests would be appreciated.