Feature Request Make Joints compatible with netcode in a simple way

The current implementation of Joints makes it difficult to work with when using netcode (apart from some basic use cases).

The main issue is that often you would like to connect two rigid bodies with a joint during runtime but also allow the joint to break.

The current implementation (when using unity legacy joint components) seems to create a child entity that contains all the joint configurations, which seems unnecessary. In addition, Netcode heavily discourages to sync data of child entities, so ideally joints should not be children.

The ideal use case (for us) in net code would be if the joint could be its own isolated entity during authoring and runtime.

We would spawn a joint ghost that has nothing connected, and when needed, these preconfigured joints can be used at runtime to create connections.

This currently seems not possible because of the following limitations by the physics package:

• PhysicsConstrainedBodyPair has its entity pair (Entities) internal, so we can't create a networked version for it, and it also can't be easily modified at runtime (requires creating a fresh component).
  
  
• During Authoring, creating a joint and configuring it requires having a rigidbody attached to the GameObject. This is problematic as it makes it complicated to create ghosts that are only joints.
  
  
• Setting both entities to Entity.Null for the PhysicsConstrainedBodyPair results in exceptions (due to an assert and some math). Ideally, if both entities are set to Entity.Null, all constraints should be skipped.
  
  
• Having one of the PhysicsConstrainedBodyPair set to Entity.Null still anchors the joint to the initial world position. Ideally, if one of the entities is set to Entity.Null, the constraints would be omitted and treated as if the joint did not exist.
  

Joints ideally should be treated as a data-only component (TransformUsageFlags.None) and link two entities together with constraints. They don't require being a child of one of the entities to which the constraint is applied, nor do they require being active if one of the body pairs is Entity.Null.

If these current restrictions were lifted, creating fully networked joints would be a lot easier and would require fewer hacks to make them work.

It would be great if this could be considered for one of the future updates to the package, to make runtime modifications of joints more accessible in a networked game.

 

For this I would like to request entities logical grouping feature at Entities Hierarch that works like current parent and child entity grouping but without required to attach Parent component to child entity to achieve it at editor only. Currently it's extremely hard to check entity that is getting unparent that scatter all over the place but they are should be group together to make it much easier to inspect. This feature is just editor only feature and won't affect player runtime. Currently I have ghost entity that using transform components to achieve this logical grouping it's suboptimal to performance so I hope official can implement this feature.

 

First of all, thank you for considering making joints work more seamlessly in combination with Netcode.

Indeed that would be possible but seems to be more of a hack than making joints a first-class citizen of netcode.
If the custom ecs physics authoring components would not require the joint to have a PhysicsBody attached and would allow `Entitiy.Null`, and use the `TransformUsageFlags.None`, we could use the joint as a normal ghost entity without requiring unnecessary parent-child relationships and represent the joints more closely to what they actually represent inside of the physics engine.

Currently, we use a separate ghost entity, which is used as a placeholder that has a Physics body attached only due to the baking requirement. At runtime, we switch the connected entities for the actually needed ones (the actual ghost entities).

This workaround works but doesn't feel very intuitive or well-integrated. For the switching, we use a similar strategy to the character controller demos used for parenting in netcode.

Removing the assert would be a great first step to allow a more flexible use without requiring to modify the package.

That could be interesting, but indeed performance concerns are critical. As a first step, if joint configurations could be more easily used (and separated form the actual rigidbodies) as prefabs to be instantiated at runtime (as ghosts) I don't think the enablable element is needed as long as the joint is "ignored" as long as both connected entity references are "Entity.Null".