Any solution for floating points on part positions?

Hi, I’m having a pretty severe issue with floating points on part positions right now and it’s kinda ruining my ability to build and I’m wondering as to what I could be doing wrong.

I’ve been looking into it and I understand many others have had this issue but I’m looking for any method to work around this. I end up with a lot of part positions like this -837.799.

But firstly, I’m not dragging the parts, I’m duplicating them and using the move tool using .2 increments. So I don’t really understand how two parts perfectly lined up after being duplicated and being moved like 30 studs on the same axis end up being slightly off.

I’ve heard that using plugins is a work around, but I’m not entirely sure if that’s true.

Anyway thanks in advance for any input and advice on this matter I greatly appreciate it!

2 Likes

I wrote a script a while ago that snaps all parts to the nearest 0.1 increment while preserving rotations.

Try running this in the command bar and see if it helps.

3 Likes

There isn’t really a solution. In fact, you will never be able to position an object at -837.8. This is due to how numbers are stored. Roblox just uses some tricks to make it seem like your object is positioned there.

When you position an object, 3 numbers need to be stored for the object’s position; The X, Y and Z coordinates. These numbers are represented in bits, some for the integer part of the number, some for the decimal part. For the integer part, these bits represent powers of 2:

5 = 101 = 1x4 + 0x2 + 1x1
10 = 1010 = 1x8 + 0x4 + 1x2 + 0x1

For the decimal part, this works a bit different. Instead of using powers of 2, you use 1 divided by a power of 2. So:

0.5 = 1/2 = 1
0.125 = 1/8 = 100
0.625 = 5/8 = 1/2 + 1/8 = 101

Using this method, you will never be able to store exactly 0.8 in the decimal part. You can only more accurately approximate it the more bits you have for the decimal part of the number. Roblox (and Lua?) use some tricks to hide this limitation of never getting 100% accurate decimals. The property window usually rounds variables to 3 decimals so it looks accurate, when it really isn’t. But for NumberValues for example, this isn’t the case; Try entering the value 0.1. In your case, the position wasn’t quite rounded expectedly in the property window.

Getting back to your question, there is not much you can do about your issue. However, if you build close to the world origin (0, 0, 0) Roblox will usually do a better job masking decimal precision and your objects will look like they’re positioned more accurately. Plugins probably won’t help you in this case though, as you already expected.

11 Likes

There IS something s/he can do about his issue though. Floating points have a precision greater than 6 places (-837.799 is off by at most 6), so having a position that is displayed as -837.8 in studio shouldn’t be impossible. The problem is that the floating point errors accumulate over time while building. Snapping them back to the nearest 0.1 (or any grid) should be a good-enough solution, unless the error gets too large.

6 Likes

Good point! I hadn’t considered that.

2 Likes

Yeah, that’s exactly my issue is really they’re super super super prevalent right now for me and it’s completely destroying my ability to make nice looking projects, I’m currently working on a very large build so building around 0,0,0 is completely out of the question sadly (aside from the props, and models that’ll populate the map)

I’m kinda just slugging through it right now but it’s still extremely aggravating qq.

Thanks though for your script, I’ll be sure to try it out soon, I greatly appreciate it. I’ll post results in regards to it later!

One recommendation would be to build your more “modular” parts of the project around the origin in a separate place and copy them into position when they’re done. Because if you’re building really far from the origin then there is no magic fix, there’s going to be more floating point problems no matter what you do, it’s just part of the reality of how computers / games / Roblox work.

1 Like

That’s a good idea actually, I’ll try to give that a shot.

Something I’ve just realized, and it’s appearing to be related to my issue I don’t get floating point errors with 1 stud increments nearly as often at the distance I’m building at currently.

I’m just mentioning this to you because I don’t know if this is confirmation bias and I don’t exactly understand how this works to well. Could this possibly be a factor?

Building at (664.6, 92, -2201) with .2 increments is seemingly causing a lot more icky numbers versus when I switched over to 1 stud increments. I’m likely going to restart and attempt your “modular” method because it seems by far to be the safest bet.

Thanks for the assistance I greatly appreciate it.

Unless you’re building exactly on the global stud grid then 0.2 vs 1.0 increments won’t make any difference. If you are building exactly on grid then you won’t lose precision because the integer positions are exactly representable. Vs. they aren’t with 0.2 stud increments. But that only matters if the whole model you’re working on isn’t offset by 0.2, or rotated by a bit or whatever.

2 Likes

Alrighty thanks, I was right by assuming it was confirmation bias in this case base off the information you’ve given me.

I’m going to restart I think using 1 stud increments and see if it’s possible to build on grid for the layout so at the very least the floor of the map will not be offset or so I’m hoping.

Somebody correct me if I’m wrong, but multiples of 0.25 could also be precisely represented by floating points. If you’re looking for more granularity, you can try that.

2 Likes

if this is true then you’ve saved me immeasurable suffering.

Edit: .25 seemingly had little to no effect on the issue from rearing its ugly head. I’m sad now.