Conversation
andrews-unity
left a comment
andrews-unity
left a comment
There was a problem hiding this comment.
Overall this looks fine to me..
jeffreyrainy
left a comment
jeffreyrainy
left a comment
There was a problem hiding this comment.
That all seems reasonable to me.
I think we'll need a bit fancier ways to synchronize physics in the future (there bigger fish to fry first, though), but this is a good solid start.
mattwalsh-unity
left a comment
mattwalsh-unity
left a comment
There was a problem hiding this comment.
Sounds good and just piggyback on what NetworkTransform does for ClientAuth for now
|
|
||
| ## Why we do not synchronize triggers and collision events | ||
|
|
||
| 1. Collision and Trigger events contain information in reference types (classes) which is not something we could properly serialize. In addition these events contain information about the components and GameObject involved in the collision. We currently have no way to serialize that information over the network. |
There was a problem hiding this comment.
could we have restrictions similar to parenting and make sure we sync at least the collisions with NetworkObjects? We'd be able to sync a net obj's ID.
I'm guessing it'd still be hard to get an ID from a material for example. Wouldn't it still be ok to sync partial information? It'd be better than nothing, no?
There was a problem hiding this comment.
We might be able to do something but it would be very limited. The collision event contains information such as:
- The collider it collided with (we cannot synchronize this it's not a NetworkBehaviour and one Rigidbody can have many and they can be on child objects.
- Contacts, contact points, velocities, impulse could in theory be synced but they would not reflect the situation on the client at the time the
NetworkCollisionwould be fired.
There was a problem hiding this comment.
we could still have a "DelayedCollisionPoint", telling users this isn't an exact point, but still something that happened in the past if you want to play some sparkle VFX for example?
It's not the mountain I want to die on, if you don't think that'd add value, we can close this :)
|
|
||
| 3D and 2d Physics work exactly the same. The only difference is that the Rigidbody2D and NetworkRigidbody2D components need to be added to the GameObject instead of the Rigidbody and NetworkRigidbody components. The `Update` simulation mode of Physics2D is supported. | ||
|
|
||
| # Reference-level explanation |
There was a problem hiding this comment.
might be worth putting a note for Brian when he reads this, that a lot of the bellow should also be included
|
|
||
| ## Synchronizing Rigidbody Parameters | ||
|
|
||
| We will not synchronize any Rigidbody parameters besides `IsKinematic`. For instance we will not synchronize the Mass or the Drag or the Constraints of a Rigidbody. The reasons we do not synchronize them are to save bandwidth and to keep the use cases of Rigidbody flexible. If synchronization of a specific Rigidbody parameter is needed users can add this with a custom script using a NetworkVariable. |
There was a problem hiding this comment.
"to save bandwidth" --> maybe I'm missing something, that's a few bytes at spawn, then nothing if it doesn't change, no?
Not sure I understand the flexibility bit.
There was a problem hiding this comment.
People might change these values but not change velocities. For instance it is quite common to adjust the mass or add constraints to a RigidBody at runtime. If the controller of the body never changes there is no need to synchronize those values.
There was a problem hiding this comment.
that's a dirty check though no? That's different from saying we'll never sync these values. It's a bit like what Fatih did with NetworkTransform's state and per-axis synchronisation.
5 participants
See linked RFC document →
RPC proposing a physics solution for co-op games.