Official Upcoming authoring changes for Unity Physics and Havok Physics for Unity

in Physics Shape Authoring we can adjust the following settings: Collision Filter (Collides with, Belongs to) and Custom tags. I use these intensively in my projects. Will they be available in built-in (legacy) physics components in some form, or we will have to use custom physics authoring?

 

I have same problem!

 

I was going to ask the same question. The authoring components have more and different settings. Additionally, the baking for the buildin joints was broken for me so I used the joint authoring components from the samples.

 

I read this as legacy physics components will no longer be supported, which sounded good.

 

@IsaacsUnity What about the lisence for Havok in Unity ? Any update on this ?

 

Why is this a sample and not just a separate optional package?

 

Are there any plans to make the "constraints" checkboxes in the Rigidbody component get converted too, so we can easily create 2D-physics entities? Or alternatively you could make this workflow apply to Rigidbody2D and the corresponding colliders.

 

I feel like it's hidden, which makes it difficult to access and reimport. I suggest, if you want to keep it in the samples tab, that you simply add a note in the description saying:
"DOTS Custom Physics Authoring Components [are deprecated (or whatever is happening with them)] in favor of the legacy physics components. The components can still be used, and can be imported from the samples tab"
..or something less wordy.

 

Having to get the user to delete the existing code and then re-import every version is not a good experience, along with having these random files in the project (Under a "samples" folder to add confusion). It's a short term trade off that is going to hurt more as time goes on.

 

For those wanting a package I've created it on github/upm:

• https://github.com/redwyre/com.redwyre.physics-custom-authoring
• https://openupm.com/packages/com.redwyre.physics-custom-authoring/

 

Why would a package with a dependency on another package impact the package it depends on?

 

Is there no performance advantage to using the Unity Physics authoring components in the physics samples over the built in physics components at this point?

 

Why would there be a performance difference? Both authoring methods create the same Entities components once baked.

 

I did not know this. Thank you

 

I totally misunderstood what was going to happen. I don't support this change.

 

How are Joints going to work with this transition? the Physics docs only list the custom authoring options.
The default joint components leverage of ECS and Havok or only the custom ones?

 

All Physics Shape authoring data are missing after upgrade and import the new sample. Is there any tool to keep data intact?

 

This happened to me as well. I removed unity physics and the sample. Which took it back to 1.0.8 because of a dependency with the CharacterController package. I then upgraded back to 1.0.11 and it worked again.

 

And now it's back to being broken again!

 

I deleted the Library folder and it's working again. But yea if it happens again I will report.

 

I just found this thread. Does this mean PhysicsBody and PhysicsShape are deprecated?

CharacterController package samples still use them. I thought they are intended to replace all built-in physics components.

So, which one does Unity encourage us to use? Built-in Physics Authoring or Custom Physics Authoring? The fact that Custom Physics Authoring has additional baker scripts, If it is not going to be maintained, everyone can imply that Built-in Physics Authoring is the practical solution.

 

Built-in is recommended for now. That said, the custom package is still available and does have some features that built-in does not. I believe it is being maintained until built-in reaches parity. At that point it would no longer be needed.

 

Because of the differences between Unity Physics and PhysX parity will never happen. I initially thought they were deprecating the legacy physics components because that would have been sensible given the differences in data requirements between the two physics packages.

This change was a marketing decision and not one based on reality. Joachim Ante had this vision that you could separate the authoring and runtime components and Unity management is running with that. The reality is that the two representations are intrinsically, and fundamentals coupled in ways that make this kind of abstraction unreasonable.

 

Can you list some of the functionality from Unity Physics authoring that you think cannot be addressed with updates to the components used for PhysX?

 

With Entities and Unity Physics, there is no PhysX involved at all. The component is just being converted under the hood. So yes, could receive parity. I'm not sure what approach they will take, however.

 

The two physics systems have different data requirements. One big one is Force Unique. Without Force Unique you cannot have non-uniformly scaling of colliders or changing collision filters at run time without affecting the whole blob.

Collision filters themselves are different from legacy. You have Belongs To and Collides With. Setting World Index. The list goes on and on because the two physic engines are so different.

At some level, Unity understands this. The docs say “If you’d like to have more fine-grained control over your Physics simulations, refer to the custom Unity Physics authoring components demonstrated in the PhysicsSamples project.” This is basic stuff that every ECS project will need. The issue is for whatever reason this is not getting through to management. Probably because unrealistic expectation where set early on.

The data is different it will never receive parity.

 

It wont receive parity on the PhysX Side. But it could absolutely implement those options in the component and have them only effect Unity Physics. That's the functionality parity I am referring to.

 

Cluttering up a single component with options increases complexity. I doubt Unity will create a workflow with that many superfluous options. If it happens it will likely be more along the line of a context-aware GUI. What is less obvious is what advantages would a single component allow? Seems like only negatives.

I don’t want to speculate too much about something that may or may not happen. Likely the current components will remain unchanged for many years to come. If ECS physics becomes more than a niche product that could change. As it stands the legacy components simply are not viable.

 

Agreed. I'm just going off of their announcement when they changed this to a sample package.

Specifically: "We intend to take some of the usability and design lessons from these custom Unity Physics authoring components and apply them to the built-in Physics authoring components moving forward."