Many parts refuse to maintain their studio-set orientation in-experience

Bug Reports Engine Bugs
,
#1

Studio:

image
image602Ă—673 62.5 KB

Experience:
image
image746Ă—597 48.9 KB

(all parts in the model have had their orientation reset to 0, even if appearances say otherwise)

As you can see from the above examples, the rails and ballast of this track model have reset their orientation to 0,0,0, when their orientation is not 0,0,0 in-studio. This has been a problem for YEARS and it is extremely frustrating to constantly tweak a parts position and orientation by small amounts and constantly opening and closing the experience in the client to try and fix the bug.

The orientation of the parts are in decimals, for example 0.072. Railway track will often have shallow changes in orientation like this because of the physics in how trains work, but regardless of how small the orientation is NO DEVELOPER should have to deal with parts refusing their orientation and changing themselves to an orientation of 0,0,0 for no discernable reason. If the orientation can be given in studio, why is it reset when a player joins the experience through the normal client?

Yes the part is anchored… yes its not being set by a script (infact even with a script to change the orientation of the parts they still REFUSE to change their orientation, when many other parts have no problem with these specific orientation values in different positions across the map)

This is extremely frustrating and quite a major bug, as not only is it visually awful, but my trains are physically incapable of traversing these segments of tracks because of the mis-alignment.

Reproduction Steps:
Create a part and give it an orientation less than 0.1 along the axis perpendicular to its longest (a slope)
Move this part to multiple different positions with a decimal value in studio until joining the published experience results in the part orientation resetting to 0,0,0.
Once a position has been found, adjust the orientation and position by small decimal amounts and you should see nearby positions do not fix this issue.

4 Likes
Meshpart not showing correctly after getting cloned()
#2

This is from how it sounds, a floating point error like you’ve possibly seen with the roblox farlands.
Decimal point values are not completely accurate on computers.

I think the only thing you can do is split your part into multiple parts so you don’t notice the orientation change.

1 Like
#3

Only thing I don’t understand abtout this floating point mistake is why it applies to live game, but not studio?

1 Like
#4

Maybe studio uses more accurate values. (64 bit instead of 32 bit floating point values)

1 Like
#5

It’s very noticeable with long Parts.
It’s rounding the decimals of Position and Orientation beyond the .001 increment.
Put 2 small Parts side by side. Say the Y axis is 25.2.
Zoom in close to the top surface.
Go into the Properties and manually enter one at 25.1995.
You’ll see the difference in Studio, but in the Properties window it will round to 25.2.
In game will round it to 25.2 exactly.
Orientation will move this way as well.

2 Likes
#6

Its definitely not related to accuracy as many other parts have perfect accuracy in-experience. This is purely a random event that I cannot accurately replicate (it seems to be random for specific parts)

From what I can tell it seems to be specific ranges of positions in the world that cause this issue. Even duplicating parts and re-typing (NOT copy-pasting) the co-ordinates still results in the orientation being set to 0. Shifting the orientation, position, and part size has no change on this orientation reset.

This is clearly some kind of engine malfunction, many other parts have no problem with these slight orientations at different positions across my map. Scripts to set the orientation of these parts with a generous wait added the line before still are unable to fix this, so I’m completely lost.

1 Like
#7

This is most likely due to how rotations get replicated, they get turned into quaternions which have less precision

#8

That’s quite frustrating to be honest. Why does studio not use these to begin with or why are quaternions used in-experience rather than the system studio uses? Its an unnecessary level of ambiguity for developers, as what we can do in studio should be the same in-experience.

#9

I would guess it saves memory bandwidth when it comes to things like physics replication, where parts are moving a lot and having the rotations in that format helps. They only get turned into quaterions during Server > Client replication as far as I know, so in Studio these wouldn’t show up. Just curious, do the rails also shift around in Play Solo/Team Test?

1 Like
#10

Is that necessary with modern hardware, or in other words is it an optimisation even needed in 2024 compared to when Roblox was first created? Surely Roblox can afford to increase precision with modern hardware to not only improve the visuals of game’s but also to give developers greater freedom?

As I patched the bug out by replacing the rails with ones that aren’t broken in-experience I’m not able to check anymore without spending hours going through older place versions, sorry!

#11

This is “by design” for now; large parts use our lossy rotation compressor. However, it’s obviously causing issues for longer parts - Maybe there’s a way for us to improve this.

Can you send a repro file with a part that triggers this behavior?

1 Like
#12

It isn’t even an issue for longer parts, when parts are affected its regardless of their size (I’ve tried tweaking part size to bypass the bug, to no avail).

It would be extremely helpful if baseparts had a property that when enabled gave parts lossless and less compressed rotation, which would be helpful to maintain performance while ensuring vital parts maintain their orientation, like train tracks or generally for parts in specific circumstances that do not properly match the desired orientation in-experience.

As I stated in my previous message to 0Tenth, I replaced the parts that had this issue with ones that did not, so I cannot provide a reproduction at this time. However if it helps, objects with near-zero orientations are more likely to experience this bug, which is extremely harmful to train (and road vehicle) games that have modern realistic track (or roads) that have gentle gradients and bends.