I made a build mode option for my game and noticed sometimes the model that I have on the client thats just to show where you’re placing the furniture glitches out sometimes (shown in the right in the picture below) I then noticed it happens whenever I mouse over the sky or somewhere in the void. I can easily just put an invisible border to fix this or limit the distance the prop can move from the character, but I want to know what causes this.
As noted from this post
https://devforum.roblox.com/t/do-you-use-the-primarypart-property-of-models-and-if-so-for-what-purposes/673556/29
Calculation imprecisions cause the model to tear apart slowly with each call and it becomes more noticeable the more you make calls.
If you are looping the furniture position to your mouse position, then it will slowly tear itself apart. It could also be possible that the huge difference in distance from the original position of the furniture to the world limit is extreme enough to cause something like this to happen instantly, though don’t take my word for it.
So you can only store decimals points as a multiple of 1/(2^n) due to storage being binary.
.25 is simple → 1/4 → 2^2 = 4
.4 is hard → its like 3.99999999999992 or something strange.
So with each change that rounding error keeps stacking.
Huge numbers have larger margins of error, this is due to there being a limit on max true representation before powers become involved.
A NumberValue stores a number in 64 bits (8 bytes) using the IEEE 754 representation (1 sign bit, 11 exponent bits and 52 fractional bits). The maximum numerical value that may be stored is 2^53, or 9,007,199,254,740,992, and the minimum is -9,007,199,254,740,992. It stores up to 15 digits of precision
1 Like
If you move it to the absolute world limit, then the parts of the model cannot be placed beyond the limit, so you end up with the parts stacked on top of each other as shown.
Either don’t move the furniture and leave it where it was last, or parent it to nil to hide it when the mouse isn’t pointing at anything (consider checking Mouse.Target or using a ray to check if there is any BasePart that would stop the furniture being placed at the world limit).
1 Like
BTW, since SetPrimaryPartCFrame is now/will be deprecated, you can use the new pivot APIs as a drop-in replacement. Pivots do not suffer from the same floating point imprecisions that XPrimaryPartCFrame methods do (pivots cache offsets) and it implements better logic internally as well (something similar to or directly BulkMoveTo).
Not particularly sure if switching functions would result in seeing the same discrepancies OP is getting right now but nonetheless it would still be good practice to follow BanTech’s advice and just improve the system so that models are incapable of moving to the world extents either by using their last valid position if an invalid one is hit or just removing the model altogether until the mouse is in a valid place.
1 Like