Resolved Future of custom Unity Physics authoring components

Custom Unity Physics authoring components have been being sidelined. Currently they offer the best authoring experience for Unity Physics. They expose more options, some of which are for very basic things like Force Unique and collision filters.


I don’t understand why this decision was taken. Runtime data is always going to be coupled to authoring data and this decision makes basic stuff much harder or impossible. What is the plan for the authoring workflow? Are legacy components going to change? What benefit does having one set of components bring compared to a tailored solution?

 

There are currently two things to maintain, after they're done bringing the built-in components to parity then there will be one.
It will also be one that's familiar to new users and means there's easy compatibility with built-in, instead of having new totally different components.
I think there's not much point being sad about it until the final authoring solution exists to discuss, because for once the previous solution wasn't just totally removed, we have it in the samples for those that need it!

 

I don't believe they can ever reach parity and they never said they would. The issue is unless Unity Physics fundamentally changes the way it works it will remain a broken workflow when using Legacy components. Instead of wild speculation, I would like some clues on what is going to happen to address the issue of this broken workflow.

 

You do not need to be aggressive to people who respond to you.



It's not wild speculation, it's what they have stated fairly repeatedly.







Feel free to search the Unity Discord for other such responses, which iirc were also covered in the previous DOTS dev days.

 

Thank you for providing those sources. I only know what I read on this forum. Not what is on reddit or discord. They do seem to take a stronger stand on reddit and discord. However, the issue of this strategy being nonviable, in my opinion, still exists.

I think this change was a marketing decision and not one based on reality. Because of the difference in data requirements between Unity Physics and PhysX I do not believe parity will ever happen. The reality is that the runtime and editor representations are intrinsically, and fundamentals coupled in ways that make this kind of abstraction unreasonable. Cluttering up a single component with options increases complexity and looks amateurish. I doubt Unity will create a workflow with that many superfluous options. As it stands the legacy components simply are not viable. However, I think we are likely to be stuck with them for a long time to come.

 

I am ok with baking, and you are right not everything has to be 1 to 1. I don’t care too much about what the baked component date ends up being if it auto bakes. I do have some reservations about complex baking scenarios. It puts a heavy burden on the programmer. It is much cheaper monetarily and more flexible having a level designer set stuff up compared to a programmer setting up baking. I think that it is probably worth it given the potential performance benefits and ease of setting up authoring for artists.

The legacy components were designed with 1 to 1 in mind. Unity Physics is also mostly 1 to 1 except for the compound colliders which often create huge issues because of their loose coupling compared to WYSIWYG. When you are trying to set a collision filter in most cases you just want the data to be baked into a single component date. In other words, the runtime data is very tightly coupled to the authoring data.

This is possibly the opposite of what you were saying. But if you decide to have extra authoring components and bake multiple authoring components into 1 run time component, I am ok with it. Even if I think it is a sign that PhysX and MonoBehaviour considerations are negatively affecting the design of the authoring components.