Improving support for non-destructive editor tools for avatars

Creator Hub Creator Feedback
1

I’m the author of the Modular Avatar suite of nondestructive avatar editing tools, as well as the NDM Framework, which aims to help multiple nondestructive tools work together. These tools work by building on top of the VRChat SDK’s IVRCSDKPreprocessAvatarCallback API, allowing us to transform the avatar at build and upload time.

That being said, there’s a number of sharp edges in this API:

  • There’s no clear guidance on how to define the callbackOrder, or a place to register where you’ve placed your plugins. [Canny]
  • There’s no support for previewing transformations in play mode built into the SDK. As a result, every tool author needs to build their own system for doing so, which can result in conflicts (this has been a problem for Modular Avatar and VRCFury recently). [Canny]
    • For that matter, there’s no official support for avatar emulation, which means tool authors have to handle multiple different implementations of avatar emulation. [Canny]
  • There’s no way to plug into the VRCSDK error display, so tool authors have to build their own UI. [Canny]
  • For tools which perform optimization and transformations to make avatars Quest-compatible, the VRCSDK checks the quest content rules prior to transforming the avatar, which can block upload of an avatar that would be compliant after running build plugins. [Canny]

(sorry if these cannys are duplicates - canny search is being particularly useless today…)

I’ve been trying to address these issues with NDM Framework, but a challenge here is that not everyone is willing to take on an additional dependency, particularly when there are outstanding VCC issues that cause problems with dependency resolution (e.g. [BUG] If there are multiple community repositories that have the common package, version list of another package will be wrong · Issue #369 · vrchat-community/creator-companion · GitHub).

It’s also not clear if resolving some of these issues would be considered acceptable from the VRChat perspective. In particular, one thing I’ve considered is bypassing the VRCSDK validations to start the build (probably using harmony), but then executing and enforcing the validations after all build hooks run. This of course has a bunch of UI challenges, but would enable having a single copy of an avatar that uploads both an optimized Quest variant and a more featureful PC variant. However, this would be mucking with the VRCSDK at a rather deep level, and I’m not sure VRChat would appreciate such things.

In short, I’m wondering:

  • How much of these issues are ones that VRChat even wants to take in-house, vs allowing the community to resolve them?
  • Is there any interest in taking some of the community-created solutions and integrating them into the VRCSDK, to improve consistency here?
  • What’s the right venue to request permission to harmony-patch the VRCSDK to resolve UI/UX issues? (taking full responsibility if it breaks in the future, of course…)
6 Likes
2

(not sure if this belongs here or in tool creators - feel free to move the topic if it’s better over there!)

3

I secretly wish VRChat would adopt or offical support what Modular Avatar and/or VRCFury does. Haveing something like this as an offical base with a modular approach would probably remove all your questions and open up for many other creators to use this as a base with all it’s VRChat logic and shenanigans in it (Looking at your 2nd bullet point here)

You asked if this is the right place. I think so, because, thank you for pushing this questions here with there referenced Canny links i have partially missed before. I wouldn’t have known this issue until i would face them myself.

4

Thank you for the well-written feedback!

I will bring these points up with the team and then get back to this thread.

5

This is exactly the kind of post I like to see here. Thanks, bd!

I’m a HUGE fan of non-destructive editor tools like yours, VRCFury, and the addons-on-addons like Prefabulous Avatar.

For some kneejerk thoughts to your wondering (none of this is set in stone, its just me reading and then thinking off the top off my head):

Personally I would love to do everything possible to support these types of tools. I think that the community will always move faster than us, and are bigger experts than us in things like avatar creation. As such, I think I’d always want the “best” tools of this type to be community-owned, and VRChat-supported and promoted.

I want to support these efforts and tools while simultaneously making it non-painful to work on them. I want to recognize and reward the creation of these tools with official “blessings” and anything else they might require.

As far as the bugs and issues you’re citing, I think many of them could be changes and fixes we implement. It’s just a matter of – as always – resources.

Iiiiiii… dunno. As I stated above, I love that VRCFury literally updates seemingly daily. I love that you can implement new experimental things into Modular Avatar at a whim. I love that Hai can add on new specialty functionality without having to tap someone else on the shoulder. The agility of these projects is part of what makes them so valuable, you know?

I think this is a “love, promote, support” thing rather than an absorb and integrate thing. We’re rather cautious when it comes to trusting third-party code and labeling it as “official VRChat” – open source software traditionally has better security than closed-source software, after all.

I think this should be a last resort kind of thing, but I also understand that the slowness in our bug and feedback resolution makes this really tempting. (again, resources…)

Dunno the answer for now…

Anyhow, that’s my thoughts. As Strasz said, we’ll get some more people chiming in here.

6

The agility argument is a good one, for sure. I for one don’t think any of this non-destructive workflow stuff would have happened if we had left everything up to the VRCSDK :slight_smile:

I think what’s key is finding what commonalities exist that are:

  1. Tricky to implement correctly
  2. A source of compatibility issues or user confusion
  3. Duplicated across multiple tools

One such area that comes to mind is the Apply on Play processing that has been a problem lately - we’re just recently getting to a good common ground, but - fitting into the discussion about how it would be nice to have an officially blessed emulator - having a common mechanism to trigger these avatar processing hooks in play mode would help a lot for maintaining compatibility with other build plugin frameworks. That being said - please do reach out to Senky and I if you do start implementing such a thing - there’s a bunch of really subtle pitfalls there, and getting it wrong would be worse than leaving it as is! (I’m still not entirely sure we’ve got it right, for that matter…)

Regarding the “promote” step of “love, promote, support” - I posted over on the tool creators forum as well, but it’s really unclear what the criteria for entering the curated packages list are currently. Certainly nothing has been added recently… Or is there something else you’re thinking about for promotion?

7

Absolutely agreed, I think that’s a great idea. One way I like to think about it is thinking of our creation tools as both an official UI and an API layer, and it seems that we’re missing some vital API calls.

Noted!

“Curated” packages is in a weird spot. They existed because we wanted to get something available for users before user repos became popular, but now, at this point, user repos are popular and easy to set up.

I would drop the idea of “curated” packages and instead move to a model where we simply “promote” packages and repos in good standing, along with the requisite warning of “hey, this isn’t our code, here be dragons”. That’s way easier, offloads some things, and allows package authors that update often to keep doing their thing without tripping up on waiting on our so-slow-its-imperceptible approval process.

8

As someone who works on another Unity project that has some amount of UGC in it, the unfortunate reality is that building on a moving target entails taking on a very conservative approach that aims to minimize exposure to risk that a supported feature becomes either unsupportable, or expensive to support.

There are many things which can be done, but which are so subject to implementation details that the most existentially stable (not just stability of cost/effort to support, but content stability and SDK stability) thing to do is to smile and approve, but not take on the support burden officially.

Although the distinction between Early Access/Release/Long-Term-Support is almost entirely artificial and has little impact on development directly, a delegation of responsibility in a way that minimizes the number of support surface area to the latter end of the spectrum tends to build a healthier ecosystem overall, because it calibrates expectations with the public and the engaged developers.

Throughout the late 00’s and early 10’s, a lot of the industry learned from and reacted to Facebook’s incredible iteration speed on its APIs and feature additions with scorn; new features reliably had splash damage on long-term projects that required constant rework and wore out contributors into their ecosystem faster than they could recover or replenish, and ultimately was one of the poisons that contributed to the death of their open application ecosystem.

As it turns out, moving fast broke things.