Changes to Add-on and Themes Bundling (4.2 onwards)

[Anthony_Gibbs]

@Cessen

The way this is being talked about at times (though I admittedly have not read the entire thread here, so I may have missed some context) makes it feel like people think Rigify will disappear or something.

I’ll admit that is also a minor fear of mine. Designing, modelling, rigging, animating, etc 3D characters is a fairly long term process/project (at least it is for me). So when it came to rigging, I didn’t want to spend all the time and try to learn every in and out of manual rigging and hence went looking for and considered a number of ‘auto rigging’ solutions.

On top of the flexible and modular system that is Rigify, one of my other selection criteria was the likely long term viability of any solution (with subscription software being such a thing now, I actually apply that criteria to everything, not just Blender addons). Rigify being part of standard Blender was somewhat reassuring that it would be there, that it would work and would be at least updated with any major change in Blender (the recent Bone Collections being a good example).

As such, to my mind, the moment it gets ‘pulled out’, it is at least a little step closer to just being like any other free addon that could be abandoned at a moments notice.

Now sure, it’s somewhat less likely with something so widely used, but it’s not 0% chance either. And I go back to Blendrig, which was basically in a development halt at one point, so it does happen.

In fact, there was even a few months where CloudRig wasn’t updated with latest Blender release (there isn’t a version that works with 4.0, that was skipped).

At the same time, the above doesn’t just apply to Rigify, but all of the addons that are getting pulled out.

[CookItOff]

@Cessen

I haven’t been a maintainer of it for a very long time, and other people (who have my gratitude) put in the time and effort to actually maintain and improve Rigify over most of its life. So my words here shouldn’t be taken as representative of Rigify as a project.

Not sure if you have been following it lately but Rigify is an extremely powerful and robust complete Rigging solution that many add-on developers target and base their own add-ons to interact with Rigify.

@Cessen

The present situation where Rigify has become so standard that many people think of it as essentially a core part of Blender is actually deeply unfortunate, in my opinion, and is exactly what I was worried about so many years ago. It’s honestly been bothering me for years.

I believe that there is a more positive way to look at Rigify being a core add-on in that, like I said above, many many 3rd party add-on developers (diffeomorphic for example) have targeted Rigify to work with their add-on unifying workflows for more creative options instead of fragmenting it. Having core add-ons that 3rd party developers know will be around and maintained helps unify workflows.

What if there had been another open source 3D application at the level of Blender taking away half of the add-on developers that currently work on Blender? Although there would be two DCCs available for the FOSS community to choose, Blender would be half as complete as it is now and the 3D workflow would be even more fragmented as it now. Narrowing focus on functions and supplying a core set of tools is not a bad thing and this allows 3rd party developers to feel secure in their time spent towards their own development tools that interact with core systems.

[sentharn]

Lots of great convo in this thread, and it’s fantastic to see the original devs chiming in (Rigify). I agree with what’s been said though: Rigify is THE de-facto, non-paid rigging platform. Blenrig5, cloudrig, none of them compare.

A more general question though: why is this being pushed so hard for 4.2? It seems like a huge change to be rushing to ram into the LTS. Setting a target date for sunsetting the internal plugins for the next LTS feels like it would allow for much more careful planning without feeling like the devs are trying to pull a fast one on users. (No offense: I’m not saying you are, I’m saying that’s a little bit what it feels like, as an end user. Subtle difference…)

[thorn-neverwake]

I can understand your feelings on this. I’d just like to express my thanks for what you created with that addon, as it’s outstanding and has worked great for my own production needs. I’ve not tried other solutions, not even been tempted to…rigify is that good.

[SpookyDoom]

@JulianPerez

Is not that we think it’s going to disappear completely, it’s that it adds extra steps to the setup of a new install of Blender without any apparent benefits, it’s not a problem for a single user with constant internet connection and no restrictions, but it does make it more complex to handle on a studio environment or for educational purposes.

Exactly this. I don’t fear that it will go away. It probably won’t. Way too many people use and love it. All of this merely circles back to the bundling and availability expectance for studios, scools and restricted environments of any sort. Hence my proposal to give the extensions platform actually a chance to be tested and matured in the wild a bit, before removing anything.

Unrelated to the extensions platform and bundling I also agree that besides Autorig Pro and BlendRig there are really no actual alternatives. Rigify so far has been the best ballance between usability, flexibility and features to me by far. And that includes many different free Plugins and native rigging in Maya. Rigify may have been an inhouse tool but those really are often among the best to me. Tools that have been used in production are often way more battleproven than tools that have been developed “purely theoretical”. @Cessen like it or not - you made something great, here. And even if it’s become more than what you intended - that’s a very good thing.

[CookItOff]

Sorry meant to reply to this part of your comment in the one above…

@Cessen

The way this is being talked about at times (though I admittedly have not read the entire thread here, so I may have missed some context) makes it feel like people think Rigify will disappear or something.

Having a complete core “Mannequin” for developers and other DCCs to target is imperative and not an issue of it’s “going away”. Other wise you’ll have outside DCCs picking randoms rigging systems or not including any at all for an easy Rigify to X option and further fragmenting pipelines. IMHO there should be at least one core full quick rigging solution that comes stock with Blender.

Unity, Unreal, DAZ along with other smaller developers targeted Rigify with Rigify specific apps. Would this have been the case if it wasn’t considered core and as popular as it is with the animation an rigging community across DCCs? Who going to write code to interact with their Million/Billion dollar DCC if there isn’t a know core feature?

[JohnDow]

@sentharn

If some common operations like that could make it into Blender it would lessen my dependency on it immensely.

IMO: That’s one of the biggest problems with Blender. Many of its tools have been ‘underdeveloped’ for years. Even Softimage XSI from 2010 can beat Blender in many areas. On top of that, there is this popular attitude among many developers towards new or extended feature requests from users: “Blender is an open-source software and if you want something, then do it yourself. Write a script, create an add-on or find the one that fits your needs online”. And that’s exactly how we got here. A lot, if not all, of features from those essential add-ons should’ve become native Blender tools a long time ago, but they didn’t. Why? Because why bother? Add-on has already solved the problem. Long story short: Blender without its addons is like a barebone car. It can get you from point A to B, but it’s not going to be an enjoyable or even comfortable ride. Without addressing issues like underdeveloped toolset and closing those gaps, Blender and its users will continue to rely on the third-party addons which is going to create more and more problems down the line.

[dfelinto]

For the records, regarding the “out of the box” experience.

Instead of allowing extensions (via their manifest) to be associated with a repository, we thought it will be simpler to simply let users pick the target repository they want to install an extension from disk.

—-

As for having some extensions (e.g., node wrangler) shipping pre-installed with Blender as extensions (and thus still updatable) that may be too much of a technical hurdle. The development team may have to decide between keeping it as core or leaving it on the extensions platform.

I’ll keep iterating over this next week.

[Ace_Dragon]

Agreed, there is no shame in Blender having a portion of a new release’s feature set be addons translated to C/C++ code, heck a number of commercial vendors in the past have gotten away with nearly all of the changes in a new release being purchased and ported plugins.

Take Looptools for instance, it is simply a set of well-defined tools that on their own are not extremely expansive in nature, how difficult would it be to integrate them into the hardcoded toolset?

It should also be noted that Python has a reputation for being SLOW compared to hardcoded tools. I know faster tools can now be made using Geometry Nodes, but that system is still in need of better ways to build and edit geometry in a more specific and precise manner.

[Anthony_Gibbs]

@dfelinto

The development team may have to decide between keeping it as core or leaving it on the extensions platform.

My vote would be for core. Outside of maybe the very odd bug discovered once a stable version of Blender is shipped, then I very much doubt it would need or have any real updates that aren’t directly linked to some new developments or changes with nodes and hence all that would be in the alpha/beta builds.

I’d also argue that the above applies to Rigify, etc. I mean with so many studios using it and other 3rd party apps/addons referencing it, the last thing they would want is for it to constantly and randomly be changed/updated which could at any point break all those other tools/workflows.

[sybren]

What happened to the ‘Dependency Graph Debug’ (depsgraph_debug) add-on? I can’t find that anywhere in the extensions, and I don’t see a preference that suggests this is now core functionality.

[dimitar]

Chipping in here from a user perspective. I am really looking forward to extension platform. Frankly, updating addons has been a mess, especially if they come from multiple sources - github, BM, Gumroad, etc. I always have had to manually check on when the updates run.

I do also note though, that the ease of use on relying on some of the bundled addons will be missed. Also, wondering how many of those bundled addons will actually get updated by anyone. Like everyone else, I tend to rely on quite a few of them.

Few questions:

Large addons

Has there been any thought on how to handle larger and/or asset-based addons? I am thinking of plant and car libraries that come in the form of addons? Presumably, it would be somehow best to sepate the assets from the actual addon. But then, I suppose the auto-updated would only work for actual addon-code.

Will there be some kind of size limitation to addons that can be uploaded to the extensions platform?

Then the next question is if some of the extensions update code could also be somehow ported to asset packs? Slightly off-topic, but Polyhaven seem to have done something of the sorts with the assets updated functionality and in their addon/assets pack (GitHub - Poly-Haven/polyhavenassets: A Blender add-on to integrate our assets natively in the asset browser)

Preset configurations

Wondering if there could be some type of configuration file like JSON or just part of the usual blender config that can specify specific extensions presets that get enabled. This might be the kind of file useful to share with a group of students, or alternatively to deploy an offline installation by automating the download process, placed into addon folder, etc. I know it’s also a bit tricky because addons go to a user’s personal folder (rightly so).

I suppose that’s like the saved .blend for user prefs, but what if you don’t want to import all user prefs, just which extensions should be enabled, and possibly automatically downloaded and enabled? That would be a huge timesaver for teaching. Furthermore (and again slightly off-topic), being able in general to import just a part of saved user preferences in a similar way to Appending an existing file could really useful. I am imaginig in the 3 line menu in Prefs to have an option to import preferences and export preferences.

And that’s where it gets quite tricky, because this new repositories functionality could easily be applied to all the preferences. I am overthinking a bit.

What is the “User Default” in the repositories and can that be something like a shared config file that can be exported and then shared with students, etc??

[Anthony_Gibbs]

@dimitar

Frankly, updating addons has been a mess, especially if they come from multiple sources

The only way that is going to change is if BM or Gumroad implement the same repository system that the Extensions Platform uses and in turn each addon author updates their code to take advantage of it. Since the Extension Platform wont have any paid addons.

For the github ones, they would have to either do the same or add them to the Platform. So all in all, if you use addons from various sources (especially paid ones), I suspect you will be manually updating for some time to come.

[thorn-neverwake]

And this is why I’ve been so adamant that the UX/UI for installing add-ons should not be redesigned in a way that is hindrance to the user to install them.

[josephhansen]

[Strike_Digital]

That might apply if it there weren’t a grand total of zero (0) standards around currently…

[josephhansen]

You misunderstand- my point being that currently there’s Bazaar, BlenderMarket, Gumroad, Github, and others as places you can get addons. Soon there’s going to be Bazaar, BlenderMarket, Gumroad, GitHub, and Extensions

[LazyDodo]

The extension plumbing is documented, there is no reasons Bazaar, BlenderMarket, Gumroad, GitHub can’t host their own repository and serve addons to their users from within blender. Given there is work being done to include an access token in the UI/Requests being done to the server end, something the blender implementation surely has no use for, I can only imagine that one (or more) of the vendors you mentioned asked for this.

[Strike_Digital]

Ah ok, that makes more sense. However, I don’t think it’s correct. In reality, not much will change. There will be the other platforms, and there will be Blender. The only difference is that the number of addons you can get directly inside of Blender will be much larger.

I really don’t see the downside.

[brecht]

I’m looking into how to make it easier to bundle a custom set of add-ons that have never shipped with Blender, for offline usage. I think over time the number of useful extensions like that will grow, and it’s good to accommodate that regardless of what is shipped with Blender or not.

I’m wondering about the process for people who have done this or tried to. Or maybe have done it with other software.

I think in the simplest case you could have done something like this, does that make sense?

• Run Blender on a computer with internet access
• Install a bunch of add-ons and check if it all works as expected
• Copy the addons directory onto e.g. a USB drive or network drive
• Set up a custom script directory in the preferences on every computer using this

The first two steps seem relatively convenient in that it works with add-ons from multiple sources, not just extensions.blender.org. The last two steps could perhaps be automated more, with an operator in Blender to copy the directory, and known location for Blender to pick up bundled extensions rather than having to change anything in the preferences.

Maybe for something like a school course this would be good?

In a more automated environment, perhaps where it’s handled by an IT department, you’d want to script it and not open any Blender user interface. Would you then want to use something like this?

wget https://extensions.blender.org/add-ons/nd/latest-compatible/v4.2/nd.zip
unzip -d /software/blender/bundled/extensions/nd nd.zip

Or would you not bother, and do it more manually whenever upgrading to a new Blender version, either through the Blender UI or a file manager?

I considered also pointing Blender to a directory with a bunch of zip files, and let Blender extract them. This however isn’t really practical for e.g. a read-only network drive, though maybe some way could be found to cache it locally. So I’m not sure it makes sense to suggest that workflow.