I have a design idea for directories file browsing vs. 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. It’s similar to the geometry nodes: Delivered early and far from feature complete - but something that works and brings value. Today was a big step in that direction but there are many limitations with what is in master now. Just please understand, that we are not where we want to be yet. So we have to be rather conservative (for the lack of a better word) with the design foundations. 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.
Later on, asset management systems should be able to integrate well into the asset browser. What if later we decide that folders are not an appropriate abstraction to group together assets?.blends which would be slow (caching is planned for 2.93). When changing directories it would have to read the assets of a bunch of.Users may want to see all assets in a single list, without directories.We’d have to show navigation controls which poses some UI problems.However there are design implications/limitations, e.g.: On the pure implementation side, having folder navigation within the repository shouldn’t be complicated to add. That is to say, it’s not a design change I can do easily.
This design is written out by Brecht and was signed off by the people involved. Assets in sub-directories would be loaded into a single, linear asset list.
The milestone 1 design, as outlined here, even explicitly excludes displaying sub-directories. Neither is it ready to be used by existing asset management systems. 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.
0 kommentar(er)
