Add support for "Coordinate system change" modifier to PhysX tab in FBX Settings

[moraaar]

Is your feature request related to a problem? Please describe.
Currently the Mesh tab in FBX Settings allows to add a modifier to the mesh called "Coordinate system change", but that modifier is not available in the PhysX tab, so the physx colliders generated for the mesh will not get the same transformation and collider and mesh won't align.

Example of a mesh using a "Coordinate System change" modifier to do an 180 degree rotation and having a physx mesh collider:

Describe the solution you'd like
Solution 1
Add support for "Coordinate system change" modifier to PhysX tab so the user can add the transformation to the PhysX collider as well.

Describe alternatives you've considered
Solution 2
Remove "Coordinate system change" modifier from Mesh tab and add a new generic section to the FBX Setting UI that allows modifiers to be applied globally, not only to an specific tab. With this solution the user will only add the "Coordinate system change" modifier once and it'll be applied to both mesh and physx collider. This also avoids the user to make errors like different parameters in Mesh and PhysX modifiers.

Solution 1 works and it's faster to implement, but the user would have to remember to add the modifier in 2 places and use the same parameters.

Solution 2 is more ideal, but it requires more work to modify the UI and the internal code to add a new "generic section" in FBX Settings. This solution would have to be careful of not breaking the .assetinfo that uses the modifier and adapt correctly.

[moraaar]

Note: Added both sig-simulation and sig-content because Solution 1 would fit more under sig-simulation and Solution 2 under sig-content.

[AMZN-stankowi]

My recommendation is to do Solution 1 for now, and long term we think about Solution 2. I like Solution 2, but that's a lot of work.

[moraaar]

My recommendation is to do Solution 1 for now, and long term we think about Solution 2. I like Solution 2, but that's a lot of work.

I agree. I didn't want to make assumptions in case Solution 2 approach was already part of an initiative or something. I'm fine with Solution 1 short term.

[AMZN-stankowi]

Nope, nothing actively planned for Solution 2. Just something in the back of my mind so far. It's a challenge to manage scene settings with a lot of product assets, you end up needing to apply certain modifiers multiple times and it can be easy to miss one or apply the wrong setting.

I think the other side of this to keep in mind is, the Python integration for scene processing. Ideally, teams would rely on that to automate a lot of scene settings work, instead of needing to manually click through the UI, and this UI would mostly be used for one-off scene files, and initial engine evaluation. I think the Python technology is getting there, we just need to improve the funnel to help with discoverability. With that setup, it's much less important to have Solution 2, the trade-offs of managing a bunch of rules in Python is much less of a problem than in a UI.

[moraaar]

Related issues:

• PhysX .pxmesh generation using the asset importer does not respect defined coordinate system changes #11330
• [FBX Setting] Coordinate system change attribute modification does not take effect #2426