Hmm. To resolve the compatibility issue, I think I'd prefer to have plugins declare what environments they're compatible with (with "vrchat" being the default). Let me noodle on this a bit and add that API first, before merging this.

This will also need tests in a UniVRM environment... I'll have to look into auto-importing unitypackages.

I think we should use upm version of univrm for testing since this pr expects upm version of univrm, not unitypackage one.

If ndmf is going to be aware of environments, perhaps we can warn if VRM version defines are not defined but installation is detected through AppDomain.CurrentDomain.GetAssemblies() (this should indicate a unitypackage installation)

Sorry for the lack of replies - I haven't been able to do much development on NDMF/MA over the past few weeks. I'll hopefully be able to spend some more time on it in December.

Thoughts for this issue:

Theoretically, there may be three types of avatar setup when we want to create an avatar for VRC and VRM.
Which strategy should we support (or recommend)?

Setup as separate avatars

• VRCAvatar (VRCDescriptor)
• VRMAvatar (VRMMeta)

Pros: Currently available.
Cons: When VRC avatar (or MA outfit) is modified, manual sync to VRM avatar (or MA outfit) by hand.

Conversion plugin

• VRCAvatar (VRCDescriptor)
  • → some ndmf plugin converts VRC components into VRM counterparts

Pros: Easy.
Cons: Requires development of conversion plugin, which may not be accurate enough or well customizable.

Universal avatar

• VRCAvatar (VRCDescriptor) (VRMMeta)
  • → some ndmf plugin strips VRM components in VRC builds, vice versa.

Pros: Possible. Proof of concept ( docs_ja component ndmf pass )
Cons: Somewhat bloated avatar.