Part Orientation Shifting When In-Game

Hello,

As a developer of a train game, I tend to use long parts like rails often. But one thing I’ve noticed is that when I test the game on the Roblox Game Client, parts like these shift orientation very slightly but the ends of the part do not line up with the next. My suspicion is that the game client doesn’t allow for as many decimal places for precision as Studio does when it comes to object orientation or position.

This problem has been going on for a while and I hope that it will be fixed sometime soon. If anyone has any clarification questions for me I’d be happy to answer them!

I hope that the Roblox Client will soon allow for more precision of part orientation, and that my game will be able to have smooth tracks in-game just as they look in Roblox Studio!

EDIT: Yes, these parts were anchored

38 Likes

Are the parts anchored?

1 Like

obviously yes lol.
This is happening to several overhead wires and other rails that are also anchored.

7 Likes

This also happens to the roads in my game.

8 Likes

I’ve experienced the same problem,
for me, it seems to be mainly for smaller longer objects.

At least I haven’t noticed it on bigger parts…

4 Likes

This is a known bug that has existed for years. It has been named “brickshift”. I have had this issue for several years with all parts in my game, including my roads and traffic signals that are farther away from the origin.

Although I don’t know exactly why it is like that, but one temporary solution is to make the rails and ties have the exact same orientation in a section, and try making the tracks and ties half the size.

Also, when moving parts in longer distances, copy and paste, don’t duplicate. This minimizes the brickshift on the multiple parts at farther distances from the origin. Try not to drag the parts as much when they are far from the origin. Undoing the moves will NOT undo the brickshift, so if it happens you would need to completely reinsert the copied rails. These methods work for me.

Here’s some examples:
Traffic light, installed May 2016, far away west of origin

Misaligned long road, installed December 2015

Minor visor issue, traffic light installed in July 2019

Sometimes it gets as bad as this:
Traffic light installed in June 2016

3 Likes

The cause of brick shift is due to a phonomenon known as Floating point errors. Basically it’s down to the ways computers handle numbers. Like have you ever inputted a whole number as the pitch for an audio and found it becomes some really crazy decimal? Thats a floating point error.

4 Likes

There’s gotta be some way for them to handle this, no???

2 Likes

Well for me I build my main models close to the origin before using copy and paste. I also tend to make sure things that need part precision are close to the origin in the game. Example: I always prefer to have my groups bus depot close to 0,0,0 in order to prevent brickshift.

3 Likes

obvously that would add a pretty big performance hit. maybe there could be a property to change it for specific parts so not every part has so much persision.

5 Likes

I would LOVE this. A toggle for parts like “ClientAdditionalPrecision” would be excellent.

2 Likes

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

3 Likes

Maybe there could be a property to change it for specific parts so not every part has so much precision! Like a togglable attribute of baseparts called “ClientAdditionalPrecision” that is off by default to prevent unnecessary memory usage, but when enabled, the client would pay special attention to the part’s orientation/position values.
Thanks for taking this into consideration and I look forward to seeing what you guys do to solve this issue :revolving_hearts:

2 Likes

Bumping this, I still have this issue and if there could be some sort of feature where long aligned parts farther from the origin can be whitelisted with more precision for orientation, that would be excellent.

2 Likes