BaseParts are scaled in the opposite direction when resized with the scaling tool

When using the scaling tool built into Roblox Studio, the part is scaled or moved in the opposite direction at a fraction of the distance in relation to the scaling.
While this effect is much more prominent with smaller parts (at-least one axis smaller than 1 stud), it affects parts of all sizes and results in small gaps between a lot of parts and models and parts becoming disconnected to the spacing the developer intended on.

The plugin Studio Build Suite offers alternative part manipulation tools to those built into Studio, and their scaling tool does not have this bug, and is the only way I am able to continue modelling in Studio at the moment.

Expected behaviour:
The part should only be scaled in the direction it is scaled, and all other vertices of the cuboid selection box should remain in their exact position. When scaling a typical part, only the vertices of the face being scaled should be moved.


When I first noticed the issue:
While I first noticed this issue in December 2023, I have noticed over the years that I’ve had many issues modifying old parts and models in old experiences, as they are for some reason misaligned or have gaps when moved back to other models that should be on the same imaginary spacing grid. This may be caused by the same bug as I am not certain when this bug first started.

This bug may be an issue with the newly added pivots, and the pivot may not be perfectly centred, especially for parts with 3 decimal places in their position or scale where the pivot position does not have enough decimal places to be precise.


This is incredibly disruptive to modelling in Studio, or scaling any kind of part, union or even meshes, as it results in loads of tiny gaps and models and parts being misaligned.



  1. Open any experience in Studio, I have replicated this in default experience worlds.
  2. Create a part and scale it down so that atleast two of its axis are less than 1 stud in size and the other axis is less than 5.
  3. Duplicate the part (this will help to display the disposition)
  4. Scale the duplicated part in a direction while maintaining your camera near the opposite face to the direction the part is being scaled in. If you continue holding click on the scale handle, you will be able to see with the transparency that the part has been shifted in relation to the original part (the one the second part was duplicated from)

While this bug affects smaller parts at a greater rate, it affects all parts at a rate linked to the distance scaled and inversely linked to its size.


An example:

This part is 1200 and 1500 studs in the x and z axis away from the origin (0,0,0) of the workspace.
When I scale it in a direction, it slowly scales in the opposite direction, when it shouldn’t be. This is a huge issue as it means it is impossible to properly scale and move parts so they are properly aligned, and this is an issue at all scales, not just the scale I am using.
(Note I am not holding shift, even though holding shift is meant to do this equally.)

1 Like

Have you tried resetting the pivot to see if that fixes the issue?

1 Like

The pivot was not edited but yes it was in the centre, resetting did not move it.

I presume this issue may be caused by the pivot having the same number of decimal places in accuracy as the position, meaning that odd-number movements would leave the pivot to be in the incorrect place by 0.0005 studs, as it only has 4sf of accuracy, when it should have 5 or 6 to makeup for this issue.

1 Like

Thanks for the report! I filed a ticket in our internal database and we’ll follow up when we have an update for you.

1 Like

What a co-incidence, I released a change which I believe fixes about a week ago. Could you verify whether you’re still seeing this?

If you are could you DM me that place file or share a reduced test case which demonstrates the issue?

I’ll see whether this issue is still prominent. I will not be sharing any repro places as this occurs in all places, as I had managed to replicate it in one of the starter places (I used the modern city place, but I presume it should affect all places).
The issue seemed to only occur, or atleast noticeably so, to small parts.

I can confirm that I am unable to replicate the bug in the same starter place I managed to replicate it in before, it appears that your fix works! I will migrate back to using the built-in studio tools to ensure I do not experience the bug in practice, and I’ll let you know if I experience any issues in the future.

Thanks for the fix! May I ask whether the issue was caused by the new pivot system and the pivot position having 3 decimal places as opposed to 4? Just curious!

No. The tools always use full precision underneath. The rounding is visual only.

The issue was a side-effect of an update to how the Scale tool processes handle summoning (holding Tab to summon the handles to the cursor). It was changed to do a computation in world space rather when it should have done it in local space resulting in loss of precision and thus bad behavior far from the origin.

Changing the computation back to local space fixed the issue.

If you want the gory details, basically two numbers that should line up exactly at the edge of the bounding box diverged significantly due to floating point rounding error being larger far from the origin, when scaling something large that divergence got further multiplied resulting in a significantly wrong position and the end of the part shifting.

1 Like

I’m quite concerned that floating point error is so bad only a thousand studs away from the origin. To be quite honest Roblox really need to implement industry standard solutions for floating point in open world workspaces, as no other games have these issues to my knowledge, not that close to the origin.

Its nice to know that internally precision is high though, although in-experience the rounding causes significant brickshift and I think that given the advances in modern computing hardware since Roblox was made that rounding should be increased, atleast on a server and desktop client level.

To be clear, this was very much a case of the code doing something wrong which unnecessarily magnified the normally reasonable amount of floating point error.

Hence why I was able to fix it (I can’t fix floating point error existing :stuck_out_tongue:).

1 Like

ah I see. Do you know how far from the origin floating point typically surfaces issues on Roblox?

Normally you shouldn’t see much at all out to around 10,000 studs.

Beyond that you may start to see visible gaps between parts if you’re not careful with how you build (doing something like scaling a non-grid aligned model out at 20,000 studs is bound to cause perceptible gaps to appear).

1 Like

I work with very small part sizes, and these gaps are actually visible much closer to the origin than that. While the kind of games I work on are miniature in nature, the gaps aren’t really visible to the player, only when modelling close-up in studio.

Do these gaps affect physics or purely visuals? Does Roblox have any kind of plan to eliminate or reduce the severity of floating point much like other open world platforms have for the past decade or two?

Unlikely this will change in the short term because there’s no magic bullet solution.

The problems get exaggerated to a significant extent due to the nature of creation or Roblox out of a bunch of parts which have to be precisely aligned. There are some ways to mitigate such as using CSG or Meshes instead of a composite Model.

1 Like

I really don’t mean to interrupt the conversation here, and I was checking for other bug reports on this particular issue, but it seems this one was the closest I could find to BaseParts being negatively impacted.

I don’t know when this issue occurred, but you mentioned calculation of positions on BaseParts and floating point precision errors.

Whenever you attempt to select a part in Roblox Studio, the selection completely drops unless your cursor is up close to the part, or your selecting a corner of the part.

As much as I’d love to make a bug report on this, I do not have those permissions, and the last time I tried making one, there wasn’t any update on the issue. Basically, no results.

Is this related at all? I thought I’d ask because you seemed to work on the Dragger beta, which likely means you work with this stuff on the regular.

Really sorry to maybe be posting in the wrong spot.

  • Could you disable all your plugins? You may have a misbehaving plugin interfering with the draggers.

  • Could you try this with the Dragger QoL Beta disabled?

  • In the About dialog what Studio version are you on?

Ah, I think I know what happened here.

I’m in the process of releasing a change modifying what collision group the cursor raycast uses. I’m guessing that face display plugin I see you using abused a non-collides with Default collision group to get the draggers to ignore that face display UX it has.

Could you link me to which plugin it is?

I’m on Version 0.613.1.6130510 (64bit)

Disabling the plugins fixed the issue. I forgot to mention I enabled the Dragger beta to attempt to fix the problem. It actually still occurs with the plugins on, and the old dragger system.

I also forgot to mention that this issue seems to be present in-experience as well.

ClickDetectors in-experience cause an issue where getting them to activate. You must click the corner of the part, and even sometimes that’s inconsistent.

This issue is present in the Roblox title “Write a Letter”, as well as a Roblox experience I work on called “R6 Dances”.

Maybe this? Having this disabled though still causes the issue I’m pretty sure. The plugin has the ability to disable the added hats on your team create ball, and it removes the instances from the workspace. How would that still interfere with selection of parts?

Here is the plugin, because I’m sure it’s this one:

I changed a setting, could you check whether the in-experience breakage you saw in “Write a Letter” is fixed?

1 Like