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!
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
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.
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.
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.
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
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.
I am also having this exact issue where only specific parts seem to reset their orientation to 0,0,0, especially when using shallow gradients.
I’ve had this issue for as long as I’ve been a developer on the platform, its always only specific parts, and never all parts.
An interrim fix may be to have a script that forcefully updates the part orientation (before deleting itself) as a child of the part(s) you want to fix.
fr, I’ve fixed it by using unions which I don’t find ideal but it works well enough. I don’t think it’ll work 100% of the time or if you have loads of parts
Unions massively suffer from brick shift when rendered, they are absolutely not a solution (quite the opposite), and unions absolutely still suffer this problem.
