The current design & implementation - which is just the first half of milestone one - a basic, local asset browser - are not ready to handle complex cases with 1000s of assets and complex directory structures. Neither is it ready to be used by existing asset management systems.
The milestone 1 design, as outlined here, even explicitly excludes displaying sub-directories. Assets in sub-directories would be loaded into a single, linear asset list. This design is written out by Brecht and was signed off by the people involved. That is to say, it’s not a design change I can do easily.
On the pure implementation side, having folder navigation within the repository shouldn’t be complicated to add. However there are design implications/limitations, e.g.:
- We’d have to show navigation controls which poses some UI problems.
- Users may want to see all assets in a single list, without directories.
- When changing directories it would have to read the assets of a bunch of .blends which would be slow (caching is planned for 2.93).
- What if later we decide that folders are not an appropriate abstraction to group together assets?
Later on, asset management systems should be able to integrate well into the asset browser. And we don’t want to make decisions for them on how files should be stored and how the resulting asset list will look like in the UI. So we have to be rather conservative (for the lack of a better word) with the design foundations.
Just please understand, that we are not where we want to be yet. Today was a big step in that direction but there are many limitations with what is in master now. It’s similar to the geometry nodes: Delivered early and far from feature complete - but something that works and brings value.
The display and filtering popovers currently contain items that do not apply to the Asset Browser, which should be addressed soon as part of T82680.