Expand modularity: community-contributed preset poses, expressions, models, and character packs

[ashledombos]

Is your feature request related to a problem? Please describe.
This is more about amplifying the modular nature of MPFB and harnessing the community's potential to enrich the software with a variety of assets.

Describe the solution you'd like

1. Introduce a rich variety of preset poses and expressions, while also developing a platform for the community to contribute and share their custom poses and expressions.
2. Create a mechanism for community members to offer preset human models.
3. Extend the modularity by enabling artists to supply character packs, such as a preset human model with a limited set of shape keys, hairstyles, and garments, without requiring a full MPFB plugin download, much like MustardUI’s system.

Describe alternatives you've considered
Adapting the existing platform, I mean the one primarily dedicated to MakeHuman (the standalone software), for these assets, or creating a separate online repository. The idea is to provide, as much as possible, a seamless user experience.

Additional context
This enhancement seeks to build upon the already vibrant community that has produced numerous awesome assets by providing avenues for even more extensive community involvement, thereby fostering a larger and more enriched ecosystem of creative contributions.

[joepal1976]

This is in principle a good idea. The main blocker is that the current asset repository is based on drupal 7 which reached end of life a while ago. It really should be replaced.

I've begun work with writing an alternative, a standalone server written in java / spring boot. It runs and is able to display assets, but is otherwise far from reaching even alpha state.

Maybe there's no way around extending the current asset repository until such a time when the new asset repo can be finished.

Ideally, there should be a mechanism for sharing at least presets and rigs before mpfb 2 is released as stable.

[ashledombos]

I lack expertise in Java, and consequently, won't be able to provide informed feedback on the new tool you’re developing. Nonetheless, it's evident that a significant amount of thought and effort is being invested, and I am keenly anticipating the enhanced capabilities this new assets catalog will bring to MPFB2 :)

Out of curiosity, and with no intention of challenging the ongoing project, I pondered the possibility of utilizing a git repository for managing assets configuration files and sources. If needed, a specific file server could host large binary files, while your own Java interface could interact with the git repositories, generating the assets catalog on the fly. To ensure I am articulating my thoughts clearly, I’d like to illustrate with some examples from projects I am familiar with, which adopt this practice:

1. Yunohost utilizes a GitHub organization for deploying app files (see here), although the catalog itself employs a specific interface (see here).
2. OpenMandriva, a project I am involved in, manages its packages via GitHub. While large binaries are stored separately, configuration yml files and sources are hosted on GitHub (see here), with the compilation farm fetching information from this organization based on GitHub commits (see here).
3. SPIP CMS operates with Gitea for its development, dedicating an organization to plugins (see here), with a separate UI for plugin management (see here).

I perceive a potential advantage in this separation between the interface and the repository:

• It could allow parallel development of both aspects. The core would rely on git, but the catalog interfaces, whether they are web or inside the MPFB2 plugin, can have their own development pace. Put differently, if the catalog is not finished, you can still rely on the raw git interface.
• It could provide an easy pathway for contributors to upload their contributions via a mechanism of pull requests from their own repo to the official organization.
• Assets contributors may manage issues related to their contributions independently.