Strange scale/drag behavior with parts smaller than 0.05 studs

PC Info: Windows 10, 22H2
Date First Experienced: Unsure, very recently (<7/3/23)
Date Last Experienced: 7/3/23

Reproduction Steps:

  1. Open up Roblox Studio and create a part.
  2. Create a second part on top of the first part, but resize its Y component (or any Vector3 axis) to 0.01 studs.
  3. Using the Select tool, drag the second part around the top of the first part.
  4. There is a noticeable offset from the second part when being dragged around.

Video showcasing the issue:

Reproduction File:
Reproduction.rbxl (44.5 KB)

Expected Behavior: Parts that are smaller than 0.05 studs should be directly touching a surface when being dragged.
Actual Behavior: There is a forced offset when dragging a part smaller than 0.05 studs on a surface.

Here’s also some footage of what the expected behavior should be (with the use of a plugin.)

When dragging the thin part on top of the surface, it is directly touching the surface and there is nothing offsetting it. However, once I try to drag the part using the default selection tool, the part suddenly offsets off of the surface again.


It’s stated that part can be less than 0.05 in size by any axis, BUT EVERYTHING related to size, will act like 0.05 if size is smaller. You can see this also on textures, decals, UV, collisions…


Somewhat expected behavior.

The minimum physical size of parts is currently 0.05. If you make a part smaller than that it will still be physically sized larger. Since the draggers use the physical geometry of objects to do their work and not the visual geometry, you see the gap you’re seeing.

You’re correct that this did change recently. It was thanks to us migrating to the new ExtentsCFrame + ExtentsSize API in the dragger code which consistently uses the physical size in all cases. Before the draggers were inconsistent, sometimes using the physical size and sometimes using the visual size.

I’m still on the fence about what we should do with this behavior. The current behavior is more consistent and does give you a more accurate understanding of what’s actually happening in the engine. What kind of workflows get made awkward by leaving things as they are?

If you need a workaround for now I’d recommend building models with such small elements at a larger size and scaling them down to the desired size later. This should be relatively easy to do with the numeric Scale property that exists now on Models.


For me I usually create a lot of graphics on walls using flat parts as thin as 0.01 studs, and it was almost always a normal for me to use the default parts to do so. I also usually did a lot of tricks using super thin parts to achieve certain building gimmicks that I was satisfied with.

Having to resort to plugins just to get this sort of behavior working again disrupts the workflow for me a lot since they have weird issues of their own that create new problems when I’m trying to build, and I personally find the minimum physical size of 0.05 not being thin enough for what I’m trying to achieve.

Also, I’m pretty sure the part size limit was decreased at one point (WITH the hitbox size being reduced too), not sure why that decided to get changed all of a sudden. Reduced Minimum Part Size - Released Everywhere!

Either way if you’re still contemplating this decision, I just wanted to know if you could maybe consider reimplementing this back in some way with the currently new system you have.

Thank you. :slightly_smiling_face:

1 Like

Ah, right, decal parts, I know that use case. What if basic Parts dragged the old way but not MeshParts / CSGs? That would solve the decal part use case at least, are there any other big use cases?


That solution would work wonderfully! I assume by CSGs, you mean unions, right?

As for other usecases, I’d usually manipulate the physical part size with the drag movement to make some unique structures, but with the new system, the offset behavior seems to now mess that up for me.

Yeah, unions. I have to think a bit more on this but I’ll likely include it in a set of upcoming dragger improvements.

1 Like

Alright then, thank you so much for this!

I did decide to keep the physical size behavior for Unions / MeshParts but this should be resolved now for primitive parts.

1 Like