2025-02-13 Online Assets & Asset Shelf meeting

Meetings
1

2025-02-13 Online Assets & Asset Shelf meeting

Present: Andy Goralczyk, Dalai Felinto, Julian Eisel, Sergey Sharybin, Sybren Stüvel

The meeting was to kick-start the Online Assets project, now that the Winter of Quality project is over. Most of the meeting was aimed at the current usability issues of the Asset Browser.

Usability

Andy explained his view on the current limitations of Blender’s asset system.

Andy’s Wishes

  • Enable Asset Shelf in object mode, for set dressing (like with the ‘Asset Shelf’ Python template script),
  • and for other things the Asset Browser supports, like materials.

Asset Browser (& Shelf)

  • Missing options for editing multiple assets at once. Lower prio is tags, higher prio is everything else.
  • and also for drag & drop of multiple assets
  • with options for “one location”, “row”, “grid”, etc.
  • Could be in the Redo Panel, or in the toolbar/header of the asset shelf. The latter is preferred, for discoverability.
  • Link vs. Instance a collection: would be nice to be able to choose on a per-drag basis, but currently hidden in redo panel, not that accessible.
  • Having these as a popover in the header would be really good.

Snapping

  • Dragging in objects respects scene snapping, is great.
  • Only works for objects, and not for collections (it’s not snapping the instancing empties).
  • Doesn’t have to use the bounding box of the collection, as that’s not (yet) stored in the asset. Could just snap the empty itself.
  • Snapping to the 3D cursor would be great too, might not be necessary as an option for dragging into the scene, though (see below).

Materials

  • Wish: Link to the scene without assigning, for assignment later.
  • Could be in context menu (see below).

Controversial option: context menu for more things

  • Right-click on asset, “Open Blend File” is super cool.
  • Want: “Instance to Scene” at 3D Cursor, “Link/Append to Scene”, etc.
  • Want: “Execute Script” (link to scene, execute, discard). Would maybe need “trust scripts” option per asset library.

Header

  • Define options for dragging into/onto things (next to append/link/follow prefs)
  • Sybren’s wish: show what “Follow Prefs” means. That’s the default setting, and to understand that default you have to know what the default preference is.
  • Context menu items can ignore that setting, and be more specific / independent.

Andy’s Issues

  • Big issue: Long names of assets are a problem in the grid view, even in N-panel. Issue in AssetBrowser and AssetShelf.
  • Possible solution: column view, small icons with full name behind it (like file browser column layout, but bigger icons than that, like half the size of the default asset browser)
  • Possible, less desirable option: multi-line names under the icons. macOS does 2 lines max.
  • Wish: show in the tooltip which blend file the hovered asset comes from.

Editing from Asset Shelf?

  • Rik Schutte (via Andy): organisation, catalogs of poses? Would be nice if that could happen from the asset shelf.
  • Sybren: automatic switching of the shown catalog(s) in the asset shelf would also be nice. That way it can be set up to only show the poses for the selected character(s), automatically switching when you select another character.

Asset Browser in Object Mode

  • What does it show? Everything?
  • Nice default: move primitives to assets, show those by default.

Online Asset Repositories

  • Sybren’s unspoken thought (guess who wrote these notes): can Blender know whether it’s on a metered or unmetered connection?
  • Delete per-asset blend file (like poses or brushes pushed to the asset library): move to system trash bin instead
  • First-time experience should be fast. This likely means that the index “file” needs to be served as multiple smaller files.
  • Care should be taken in terminology:
    • “cache” should be something ephemeral, where files can be deleted by Blender at will. Such a directory is not expected to be used as a local asset library, but only as a way to avoid re-downloading the same file on every use.
    • Other uses, such as a a directory used to download assets and subsequently have those available to other users (either via SMB/CIFS/NFS or systems like SyncThing, Dropbox, etc), should not be named “cache”, but rather “local storage for remote asset library” or something like that.

UI stuff

  • “All Libraries” only shows already-downloaded assets.
  • When selecting specific remote library, warning will be shown when offline or online access was denied.

Making an actual Blender asset lib

Part of the project: getting an online repository of curated assets. Should be discussed with the studio who’s going to build these assets.

OpenAPI/JSON/Tools discussion

Sybren will continue investigating options. Likely outcome (at the time of the meeting):

  • OpenAPI used for defining the API and generating Python code.
  • Pydantic as a tool for client-side validation.
  • Simplicity for Blender developers is paramount; should not have to install a dozen other tools and learn three new languages.
  • Division between Python and C++ JSON handling:
    • Python will be used for fetching remote JSON (via the requests library), validation, and transforming into local data.
    • C++ code can keep using the current JSON library (or upgrade to something better/faster), and limited to Blender-written (and thus considered safe) files.

There will likely be two API “flavours” defined:

  • Static API: for serving files from a static server. No back-end server needed. Might be less optimal for large/often-changing repositories, but makes serving a simple set of assets super simple.
  • Dynamic API: for serving API requests with an actual back-end server. This is a necessity for larger/often-changing asset libraries, more granular access control, etc.

At first only the static API will be implemented. But the API definition will at least have an explicit place where the supported API can be declared, so that in the future this can be expanded.

Server-Side File Layout

It must be possible to serve an asset repository simply by plonking some files on a static server. Proposed URL layout:

  • Base URL can be bare domain or a directory in there: https://example.org/my-awesome-library/
  • Basic meta-information about the repository will be at $BASE/_blender_assets/v1/meta.json
  • That meta.json defines:
    • Name of the repository.
    • How many assets are available.
    • Whether this repository uses the static or dynamic API (see above).
    • URLs (can be relative) to the index file (which will list each available asset).
    • Pagination options for the index (so it can be broken down into smaller parts)
  • Users will add a remote asset library via its URL. That URL can point to:
    • The base URL (this will be the most common case), or
    • the URL of the meta.json file.
      The latter option is useful when uploading to a bucket-type storage, where URLs of files can be wildly different. That way the meta.json can define absolute URLs for the index files, which in turn can have absolute URLs for the assets, thumbnails, etc.

Note that the paths & filenames are not final, and will likely change to try and stay away from path length limitations.

Tracking the project

Dalai made a tracking task: #134495: Online Assets: Remote Asset Library

Julian will make a separate task for the usability issues & wishes described above.

6 Likes
2

I gather that it was decided that one repo = one asset library path is taken forward, rather than one repo = multiple asset libraries (like how it works with add-ons). I have strong dislike for that, not only because it’s bad UX in my opinion, but also because it creates a drastic difference from how add-on and theme extensions work, and UX isn’t unified for all extension types. I feel like having to learn the differences between handling different extension types is gonna be one of those things users will complain about in the future, and we’ll excuse it with history.

Sorry for the little rant.

My question is if the role of the extensions platform has been discussed in this. There is mention of currated online asset repositories. Are those gonna be on extensions platform? Is the plan to ONLY allow currated assets from studio on the platform? That idea has been discussed before, and I don’t really like that. I understand concerns of licenses, but I don’t think it’s too much for us (me primarily) to deal with. A LOT of users are waiting for assets on the platform, it’s a daily topic almost, and if they’re not allowed to upload stuff it’s gonna be huge blow for community.

Deciding on that is important for asset browser behavior as well. It was proposed I think in one of the previous meetings to have ability to browse online assets from asset browser and support individual downlods, so how will that work in practice is dependant on how many libraries there are on the platform. Do we ship Blender with default asset libraries/repositories added in preferences? (little rant contd: assigning new meaning to repository and having it mean different thing for add-ons and different for assets is gonna be nightmare)

4 Likes
3

Not sure if that’s what’s been explicitly decided, but that’s what we’ve been discussing, yes.

AFAIK asset libraries are not extensions. We might make something similar to the drag&drop to install an asset library from the web into Blender, just like with the extensions.

Is the plan to ONLY allow currated assets […] on the platform?

Yes, that’s the plan. Who is going to curate, and who is going to create those assets, that’s still an open question. So it’s not by definition limited to assets from Blender Studio.

A LOT of users are waiting for assets on the platform, it’s a daily topic almost, and if they’re not allowed to upload stuff it’s gonna be huge blow for community.

Out of curiosity what this blow would be caused by: was this promised somewhere? I mean, such a blow can only be a blow when there are expectations of something, and then those expectations aren’t met. Personally I’ve never seen anything that suggested that the extensions platform would host community asset libraries. But then, there’s a lot on the interwebz that I don’t see. Hence my asking about this.

There are a few motivations for this project:

Bundled Assets

There is a desire for Blender to ship with a richer set of built-in assets. Things like base meshes for sculpting, predefined materials, ready to adjust-and-use-and-play-with-and-learn-from GeoNodes setups, those kind of things. Basically to give people more interesting things to play with than just a cube. I love Suzanne, but even she doesn’t really convey the current power of Blender.

These assets can take up quite a bit of space, though, compared to Blender itself. Having every build of Blender include those would be a waste of space, especially for things like daily builds. Also it is expected that these assets don’t change that often, and so the same asset could be usable for multiple versions of Blender.

These two aspects (large files, not bound to single Blender versions) show that it’s reasonable to offer these in a different place, where they can be downloaded once and used from within multiple versions of Blender. This is one of the first goals of the project, to make this possible.

Third-Party Assets

Of course such a system should be usable by others as well, so that anyone is free to offer their own assets as an “online asset library”.

This is of course also taken into account with the current design. It is intentionally made simple to host your own assets in an online library. This is why there’s support for the “static API” – just plonk some files somewhere and people should be able to use them.

Ideally it would be possible to publish such libraries via file sharing platforms like Google Drive, Dropbox, OwnCloud, etc. but at the moment that’s too specific and too complex to build into the very first rendition of the “online assets” feature.

Blender-Hosted Third-Party Assets

This is something I’ve personally thought about, but not considered, at least not yet for this first version of the system. Hosting potentially large quantities of large files (contrary to add-ons and themes, which typically are small text files and a few images) has a considerable cost. Infrastructure needs to be built & maintained, bandwidth has to be paid for. And then there’s things like liability, copyright claims, etc. that I simply don’t know enough about to say anything meaningful (apart from that I personally find it a bit scary).

Coming back to your original point (one repository, added to Blender as one thing on one URL, hosting multiple asset libraries), I think that makes total sense when you see the extensions website as a way for people to share their asset libraries. I can see that work for studios as well, where they’d have one “studio asset repository”, with a library for each project.

I’ll have to have a think about this, to see how much complexity it would add to the system. Or if we can implement things in a simple (one repo == one library) way that’s still extendable in the future (to one repo == multiple libs).

4 Likes
4

Out of curiosity what this blow would be caused by: was this promised somewhere? I mean, such a blow can only be a blow when there are expectations of something, and then those expectations aren’t met. Personally I’ve never seen anything that suggested that the extensions platform would host community asset libraries. But then, there’s a lot on the interwebz that I don’t see. Hence my asking about this.

Well we can be technical and say no one has explicitly said that users would be able to upload asset libraries, but order of things was like this:

  • Extensions platform published, where we allow users to share their add-ons and themes to other users
  • We promise that assets are soon coming to extensions platform

Users do 1+1 and start expecting to share them. On public forums, Youtube comments, discord chats that’s all people talk about. This is quite exciting next step for Blenders future. Famous asset creators, especially geonodes wizards are always reminded of that.

I think there are two goals here, both equally important, but we’re prioritizing different things. One is Blender shipping with more assets, which is amazing and I 100% agree that only studio-curated assets should be enabled/available/visible in Blender by default. No doubt about that.

Second goal, which is my priority as platform mod and asset creator, is to give people ability to share assets just as easily as add-ons. This is I think THE biggest next step for Blender, most exciting possibility. Extensions platform had unreal positive impact on Blender UX, and same for assets is gonna be same.

I understand concerns, and I think we can navigate those better. For example, large library sizes and copyright issues are not a problem for brush assets, geonodes packs, shader nodes, compositor setups, objects, pose libraries and etc. Yes there is work to be done to check if they pack embedded images and if they’re CC-0 or whatever is applicable, but that’s not a big workload on moderation.

But the harsh truth is that no matter how good we make third-party hosting, it’s not gonna happen. It’s almost 1 year since extensions platform beta launched and we’ve been telling people they can host their add-ons on other platforms if they can’t / don’t want to host on ours, and not a single other platform popped-up in that year. Not even BlenderMarket finished it yet. So situation is that if something isn’t on the platform it’s scattered, you have to search for it, discover its existence somehow on forums on youtube videos, nowhere to browse, to search. If this is gonna be case for assets as well we didn’t help much, and I’m very confident that it will be the case. Users will have to search for links to google drives in BA thread comments just to get geonodes.

I strongly believe we can support both goals together and platform should allow assets, and we can start with lightweight ones, we can develop rule about maximum filesize (there is already 200mb cap). And I think one repo = multiple libraries concept that add-ons have should be kept. Once you add repository in “Get Extensions” tab you should be able to see all add-ons, themes, and assets hosted there (in preferences, not in asset browser. Only enabled ones should be in browser), and you should be able to browse. I was skeptical at first, but from what I’ve seen and what I’ve been told people actually get add-ons from inside Blender, without even browsing on website. That is very good feature, and will make even more sense. Imagine configuring new Blender, start working and realize you want some good scattering tool. You go into preferences, search for “Scatter” and install whichever you like best, and it appears in your modifiers list. Opposite of that is going to google, searching on shady websites, navigating through AI hallucinations, and finding link to somebodies personal website you don’t know you can trust. Not liking that one.

Lot of Blenders communication in past years was that certain paths are taken in development because Blender wants to become more asset-oriented software. If we now limit the ability to share assets it will not feel correct for users. And Blender studio can’t take all the weight, can’t develop all the necessary and popular tools, it’s just gonna be too much work. Community should be able to help with that.

13 Likes
5

Disclaimer: what I write here is just concerning the here & now. In the future there may be ways to make more things possible, I don’t have a crystal ball.

I’d like to see where that was promised, because I wasn’t aware of this. Not that I don’t trust you (you know I do), but I just want to see for myself what the wording was, where it was said, etc.

large library sizes and copyright issues are not a problem for brush assets, geonodes packs, shader nodes, compositor setups, objects, pose libraries and etc.

I see things differently here. Objects (with meshes, materials, etc) can most definitely be infringing on copyright, and that might not be easy to check.

Blender can’t host a BlendSwap or BlenderKit or (insert other big asset website here). The funding for it would have to come out of the donations, and it’s already hard to keep things afloat.

At Blender Conference I’ve talked with the BlenderKit folks. They’re running an ElasticSearch instance to index around 60k assets (if not more by now). The index itself is already gigabytes in size. Then there are always people keyword-spamming to try and get to the top of the search results, so the search parameters for the ElasticSearch instance are regularly tweaked manually in order to keep things fair. Currently there is no way that Blender Foundation can pay for such infrastructure, hire people with knowledge in this area, and the time/effort to keep this going well, and still keep Blender development going at the same time.

If we now limit the ability to share assets it will not feel correct for users.

There is no limit there. Everybody is free to host a website with their assets. Currently many creators on Patreon, Gumroad etc. use links to Dropbox / Google Drive / etc. to share their assets. When this remote asset system is in place, maybe someone will write some code to make Blender natively access such remote systems as well. That could work well with the proposed static API.

One thing I want to get off the table: just because people drew certain conclusions, that doesn’t mean that anyone is mandated to implement that & pay for its existence. The whole concept of “now limiting the ability to share assets” is a little bit twisted IMO. A way to have access to assets is added to Blender. Yes, that addition is apparently more limited than what people were hoping for, but that doesn’t mean that new limits are put in place. It’s just that the expansion is less expansive than they hoped. Let’s keep the perspective positive.

As I already wrote, I’m going to look at the technical side of your proposal, and see if this is something that can be built into the current system, so that there could be room to expand into this area in the future.

And Blender studio can’t take all the weight, can’t develop all the necessary and popular tools, it’s just gonna be too much work. Community should be able to help with that.

That’s why I said that it’s still open who’s going to do the curating, and who’s going to do the creation of those assets. Of course people in the community are welcome to help out!

7 Likes
6

I don’t want to put quotes and put anyone in awkward situation, and also because you’re right, this is twisting things. Two separate announcements were made: extensions are becoming a thing, which will be addons, assets, keymaps and themes, and that Blender would launch extensions platform for add-ons and themes. But my point is that it’s really difficult to not get incorrect expectations when you’re exposed to those news. Initial announcements for platform said that we were focusing on add-ons for the moment, which invites room for speculation that assets are next.

I totally agree this is 100% positive. After all this is additive change, it’s only gonna add more cool stuff, it’s not taking anything away or even changing anything for worse. But as I said I see two goals here: shipped assets with Blender and ability to share assets, and I think people who expected second will be disappointed. Doesn’t mean first one will not get everyone excited of course.

I see things differently here. Objects (with meshes, materials, etc) can most definitely be infringing on copyright, and that might not be easy to check.

Is this gonna be problem for Blender? Because add-ons now can do that as well, they might be shipping copyrighted, non-GPL python code, they also include images, matcaps, node groups, base meshes and etc. Basically everyone who wants to ship assets now wraps it as add-on, because there is no other way (one more thing I feer will be common in the future: people will bypass asset extensions just to use features of add-on extensions) and we don’t check for those, we can’t realistically. My assumption was that if copyright infringement is found it’s up to developer to respond and only thing we should do is take it down.

We have add-ons now that come with quite a lot of assets, like… A LOT. We should be concerned about those too then, or make rule for future to only accept code. What we do now for moderation is just to point out that it’s their responsibility to make sure copyright is not infringed.

That’s why I said that it’s still open who’s going to do the curating, and who’s going to do the creation of those assets. Of course people in the community are welcome to help out!

Definitely. I hope at least it will be more relaxed, so that trustworthy sources, like artists that are close to modules, like Erindale can share too. But I’m not sure community-curation is gonna be feasible, it’ll always gonna fall on us.

5 Likes
7

As someone that up to fairly recently spent their online life with a monthly data limit, I’m just going to quickly chime in here.

To answer the question, I’m willing to bet that no, Blender can’t know, in fact, even Windows doesn’t know, unless you tell it. Outside of maybe mobile sims that could store or feedback the data plan details, etc, then really only the user knows if they are on a metered connection.

As such, the first thing that is very important, is clear indications of actual file sizes (without having to start the download and try to find or see some info box to give any idea of the size).

On that topic, once a download is started, a nice info ‘panel’ that then shows download progress, current speed, estimated time, etc is all very useful.

Finally and this is a big deal for anyone with slow, metered and/or unstable connections, the ability (as much as is possible) to resume any download that cuts out, gets dropped, has to be paused for some reason.

There is nothing worse (being on iffy Internet) but deciding you really want/need this 2GB+ file which is going to take 70mins to download and use 1/10th of your monthly data, to get it 95% complete and have it fail. Then, be forced to have to start the download all over again, even tho in theory, 95% of it is sitting in some temp folder or something.

While that isn’t me now, that was me in the past and I guess it’s possible it is still reality for some people in the world.

6 Likes
8

3 posts were split to a new topic: Potential extensions copyright issues

9

Strongly agree with this, I’d love for (online or fully downloaded) asset libraries to be just another type of extension users can enable. Even if on a technical level it being an extensions doesn’t do much besides pointing to a URL, I think the UX benefits of only having to manage repositories and enabling/disabling in one place are really significant.

Check the original blog post:

Whenever the word “extension” is used in this document, one of the following is implied:

Plans can and sometimes have to change, but the idea certainly was there from the beginning.

9 Likes
11

I think there some lack of context but geometry nodes is a way to create tools and assets without python at all, providing them as extensions by some creators currently is more like hacking to at least made something.
Every time something is designed in geometry nodes one of the main goal - make it such low level to allow technical artists create whatever they want. The other side of the coin is - there is no button make as _pask class of tasks_-artis want. For instance, you simply can not re-create current built-in instancing feature with geometry nodes in just one click, this have to be designed solution, see Remove legacy instancing.

And if we would able to embed some already existed built-in features into blender (like shade smooth modifier), and in future provide new features via online asset repository, i think its also about solutions provided by users, like other implementations of particle physics of hard-surface modeling node tools (not sure blender would be able to just maintain all of them even as online assets, this is something that should be outsourced and just use blender platform for sharing, communication (maybe also use this in development purpose for automation testing, benchmarking and technical feedback)).

Personally, i just do not see any difference between python and blend files as something to share, but i would prefer blend files with just a things over then a some script.

2 Likes
12

Thanks all for your feedback.

After some discussion with @dfelinto and @julianeisel about this, things have gotten a bit clearer. In short, the confusion / disappointment seems to come from the differences in scope of various posts about the topic. And probably also about inconsistent use of terminology here and there.

To clarify, these things are distinct:

  1. Online Asset Library. This is a set of files, .blend and otherwise, together with metadata in some index file. In the future, Blender will understand that metadata, show the assets of that library in the asset browser, and make it possible to download & use those assets. This library is available at some location, identified by a URL.
  2. Asset Library as Extension. This is about how to find these asset libraries, whether they are available as an extension somewhere. This could be an addition to extensions.blender.org, or at a self-hosted extensions website. This is also available at some location, identified by a URL.

I think this way of reasoning about things is quite nice. An “asset library” is always a single asset library. And an “extensions website” is a place where multiple extensions can be published, including (references to) multiple asset libraries.

To give a concrete example: when a creator wants to publish their asset library somewhere private, and only hand the URL to Patreons of a certain level. In this case, IMO only point 1 above is relevant. They should just be able to upload a set of files somewhere, and give the URL to people. This keeps the simple case simple.

When this creator wants to expand, and offer multiple asset libraries via a single URL, that could be done by hosting an “extensions website”. I put it between quotes because Blender doesn’t even need a full website, it just needs to have a specific JSON file (the “extensions index”) in order to discover & access extensions. How this JSON comes to be, that’s a different discussion. But once it’s there, they can just share the URL of that, and Blender sees an “extensions website” with multiple asset libraries.

Given that both points 1 and 2 above have a URL, we could even make Blender recognise what kind of thing it links to. That way there could be one place to manage these (the “Get Extensions” tab in the prefs), and from the Blender user’s perspective there is no difference between “extensions site that publishes asset libraries” and “single asset library”. You add the URL, and get access to whatever it points to.

But once you’ve told Windows, can Blender know? I really like SyncThing (or maybe it’s SyncTrayzor, the app I use to manage SyncThing) automatically stopping synchronisation when you’re on a metered connection. It would be really nice if Blender doesn’t start auto-downloading things in such a case. I wouldn’t know how to query for this, though.

And yeah, reliable re-tries are super important. Even when your connection isn’t limited (in terms of data use), you could be on a mobile connection that changes its IP address once in a while. That means broken connections, which should be handled gracefully when downloading big files.

4 Likes
13

PS: for completeness, here’s the last code blog post about the topic: Online Assets Workshop Report — Blender Developers Blog

14

The decision to separate asset libraries from extensions always seemed odd to me, so I’m happy to see it revisited. If the rationale is “simplicity” I’d ague it actually does the opposite, as Brecht suggests.

My current view on how this should work is this: Online/remote asset libraries should be available as extensions using the normal extensions UI, but additionally passing a URL that directly points to a remote asset library should be supported too. The latter is important because hosting an extensions platform is rather involved currently, so it’s not a good option for users to share an asset library. That could be solved in future still.

I think that’s what Sybren is suggesting too (we discussed this in person earlier).

For now I don’t think we can afford hosting custom asset libraries on extensions.blender.org. Yes it would be amazing for the community, but it looks like a big infrastructure challenge (in addition to the moderation needs).

2 Likes
15

Maybe?
For example in Windows 11 one has this option in the control panel

image
image802×183 17.1 KB

From memory Windows 10 only had a check box for “metered connection”, I don’t think it had any way to enter an actual limit.

So, in theory, that setting/limit is stored in the system registry and if so, then a regedit or PowerShell type command line would allow Blender to read said setting and take it from there.

1 Like
16

Ome thing ive been thinking about is what if extensions platform allowed creators to host files themselves, and provided ability to share. It would benefit users because they dont need to discover those libraries, they will be searchable in the preferences. But once you download it downloads from personal website.

Of course this requires moderation to make sure website is safe, so its more difficult job moderation wise (and would be stricter) but in long term might be more feasible alternative than Blender hosting everything.

17

Maybe supporting node groups and materials could still be considered if general assets are a problem. Assuming they are not allowed to embed e.g. big images. At least bandwidth should not be a big problem for those, we can even make such blend files much smaller by stripping out unnecessary UI and DNA if needed.

6 Likes
18

Is it worth or has there already been a conversation around the need or reason why some ‘assets’ have to be a .blend file.

My current thinking is something like how ComfyUI works for AI image generation. It works totally on a node based system and you can get some pretty complex workflows. But at the same time, the whole node setup can just be saved/exported as a JSON file.
So someone else can upload/download (a very small file) and then open (better yet, can just drag and drop on the ComfyUI workspace) and the whole workflow appears.

This would make exchanging Geometry Node setups very small and easy, without the whole overhead of a full .blend file and you could still save/store each setup per file within an asset library.

I’m sure there’s pros and cons, but plenty of other software use specific files/formats for asset type data, like brushes, materials, etc. One that directly comes to mind is Substance Painter. I have my own asset library folder (which I point the software to) and within that I’ve stored and organised all sorts of downloaded material/image/hdri, etc files that just get loaded in when I start the software.

But those are all their own file formats, some common (like png, jpg, etc) and some specific to Painter. But none of them are the main Painter file format, which contains all the working data and is usually rather large.

Blender, on the other hand, for some reason, seems to always want to store everything via the .blend file format and nothing else. Be it a whole scene/animation or a single material node setup.

3 Likes
19

My view on this: one way of reading/writing the data makes it quite a bit easier to develop. There is already a lot of versioning code to ensure old blend files can be read. Having to effectively duplicate that to also version other formats (like JSON) is an additional load on the development team, and can easily get out of sync with the other versioning.

But let’s keep this thread about what was discussed in the meeting (and its consequences on designs going forward).

20

Created a design task for the potential usability improvements: #134755 - Asset System: Usability Improvements - blender - Blender Projects

I’m not sure what this means. Is it snapping options? I’m not sure which snapping options were discussed if any.

When “All Libraries” is selected (the default), this can change based on the active asset. Assets from all libraries are displayed and each library may have a different default configured in the Preferences. Maybe once this is a popover we can display some hint. Or, maybe better indicate this clearly while dragging, potentially with a way to change it.

21

I’m not sure what this means. Is it snapping options? I’m not sure which snapping options were discussed if any.

This includes:

  • Insertion Point: [Snap | 3D Cursor]
  • Batch Insert assets: [Insert Point | Grid | Line], distance
  • Import Method: [Follow Preferences: [Mixed | Append | Append (Re-use) | Link ]

Not sure which ones should be options on the header, which ones hidden under a menu. But that’s part of what Pablo will come up with.

1 Like