Physics Elasticity issues, Automatic NetworkOwnership problem and server to client simulation wrong prediction, playtest replication issue

Bug Reports Engine Bugs
,
1

Description

The first video showcases the issue with Automatic NetworkOwnership. You’ll see that it’s trying to fight between this NetworkOwnership before finally setting NetworkOwnership.

Video 1

 

The second video shows how the ball bounces back up even though it never hit the floor on the Client. This only happens if the Server has NetworkOwnership which makes it like appear to the Client in some way.

Video 2

 

The third issue is shown in the Private Message. Where sometimes the spheres would randomly stop bouncing during the playtest. This happened when more than one sphere was present.

 

The fourth issue is probably just how automatic NetworkOwnership works? I never recall it working like that. But when you walk outside a certain radius, the bouncing spheres would lose NetworkOwnership, while you’re in the radius it would gain NetworkOwnership. But this behavior is inconsistent, and if it happens, I believe I witnessed the spheres to break from their bouncing cycle where then, they’ll just stop bouncing (which is not supposed to happen).

 

The fifth issue is also shown in the Private Message. Where the Server changes the Color of the sphere but it doesn’t replicate over to the Client during F5 Playtest. However, this issue doesn’t happen if some flags are turned on, so I believe it’s fixed in the future? Maybe Next Gen Replicator.

 

The sixth issue is a case where Roblox Studio crashed.

 

But this post focuses on the first four issues that I listed.

 

 

Re-production Steps

  • Create a Part and turn it into a Sphere
  • Elasticity 1 and ElasticityWeight 100, which turns it into an infinite bouncing ball.
  • Observe

Place files and videos are attached in the Private Message.

Expected Result

  • Smooth NetworkOwnership transition between moving bouncing spheres, when forced set.
  • Smooth NetworkOwnership transition when it automatically sets it, no “Red NetworkOwnership”. I wonder if it had to do with it going outside a certain radius.
  • When the Server owns NetworkOwnership over a bouncing sphere, the Client should not witness the sphere bouncing back up when mid air, on when rendering through the floor partially.
  • Contact Points, show up? Maybe they’re not meant to show up if the Current DataModel Perspective doesn’t have NetworkOwnership.
  • Bouncing spheres should keep bouncing and not stop bouncing when there’s more than one sphere put next to eachother.

 

The purpose of Elasticity 1, with ElasticityWeight 100, was to immitate this.

 

Actual Result

This piece of physics is unreliable with its behavior. The bouncing sphere’s can randomly stop bouncing if there’s more than one placed.

  • There’s no Smooth NetworkOwnership transition between a bouncing part. (See Video 1)
  • If the Server owns NetworkOwnership, the bouncing part can bounce off mid air, or while “appearing” through the floor. (See Video 2) The prediction seems to be wrong.
  • When playtesting, some of the parts stop bouncing, compared to when there’s just one.

 

 

Place files and more videos are attached in the Private Message.

A private message is associated with this bug report

1 Like
2

Hi Karl, thanks for the report!

I’ll run through these one at a time:

  • Smooth NetworkOwnership transition between moving bouncing spheres, when forced set.

Agreed, the change in ownership is very jarring, it’s something we are working to improve.

  • Smooth NetworkOwnership transition when it automatically sets it, no “Red NetworkOwnership”. I wonder if it had to do with it going outside a certain radius.

An explanation of the colors can be found here. The same improvements we’re working on for the first bullet point will also apply here, and should make the trajectories smoother.

  • When the Server owns NetworkOwnership over a bouncing sphere, the Client should not witness the sphere bouncing back up when mid air, on when rendering through the floor partially.

This is likely caused by our interpolation system. Since we replicate at a lower frequency than we simulate, we use interpolation to “fill in the gaps”. In this case, the Client is probably receiving data just before and just after the bounce. In that case, it has no knowledge of where the bounce occurs, just that the sphere changed direction. The interpolator has to guess where the bounce occurs, and it’s usually wrong because it’s extremely difficult to interpolate something moving with a discontinuous velocity.

  • Contact Points, show up? Maybe they’re not meant to show up if the Current DataModel Perspective doesn’t have NetworkOwnership.

Contact points are only visualized for whoever is simulating the collision, i.e. whoever owns the colliding part. We don’t plan on changing this.

  • Bouncing spheres should keep bouncing and not stop bouncing when there’s more than one sphere put next to eachother.

This is a great find! I believe this is a bug caused by adaptive timestepping, since disabling adaptive seems to fix it. We’ll investigate.

2 Likes