[Bf-taskforce25] Elubie Asset Manager

[Ton Roosendaal]

Hi Andrea,

As promised, here's feedback on the proposal as well;

In general: the main problem I see is that you try to expose an 
interface with methods not supported by (or reflected by) the system 
itself. It would therefore be much better to first thoroughly evaluate 
and redesign the system itself, before making a new UI for it. To just 
list a few issues;

- "Asset browsing" with previews is of course very cool; it could be 
used even as alternative for the 'search link' menu as used now, to 
provide greater detail. But, that also shows a problem; there's 
basically no difference between a local material linkage or one coming 
from an external file. Both are similar actions, and should be provided 
uniformly. An asset browser ideally should show everything, linked and 
local.

- "Asset manager" (or maybe call it "Library Manager") is another way 
to look at this; this is what the current library system really lacks, 
and something we should look into well. There's really a lot of issues 
to look at though... especially being able to view dependency trees or 
diagrams, or other ways to find out where data comes from really. And 
new ways to move such libraries or relink to other libraries with 
remapping of names, or even fully unlink specific data items.
We also should not forget to include dependencies on external files 
such as images, scripts, plug-ins, movie files or sounds!

- The current library system works on two levels: first it opens the 
.blend itself, and makes it browsable for ID names. At that stage no 
data is being read (no previews possible really), nor dependency 
linkage happened (like material -> nodes -> textures etc). That step is 
another action, which currently happens on the Library Link stage. Only 
after indicating you intend to link data, the .blend is being parsed, 
all linked blocks are being evaluated, dna-converted, and even 
depending new .blend files are opened in a recursive process. The 
system then marks *direct* linked blocks (like the material) seperately 
from *indirect* linked blocks (its texture, nodes, images, etc).
This is an essential library feature!

- The library system design was also based on just providing a 
compacted "file system". When I designed the .blend, many of the other 
3d packages (and I think it still is common) create "project 
directories" with inside directories with the internal assets. Every 
.blend is therefore actually a directory. It has been discussed to make 
a feature to either split .blends or to save only specific data inside 
a .blend, has to be looked into.

- When you create a bigger (film) project, one of the design stages is 
to also design a "library system" of directories and .blend files. That 
is a logical and studio-wide shared file system, typically in svn. 
Using and designing a structure that makes sense is an obvious step, 
and should simply be exposed in an asset manager too. Confusing this 
with locally editable new "groups" will only pollute the whole 
concept... to be able to share libraries together, agreeing on which 
files to use from where is a very acceptable and useful step.

- We don't need a direct 'delete datablock' option, but we do need an 
efficient 'unlink from all users' option (with recursive option), and a 
'show where the users are' option. That will give sufficient control 
over data, and makes a final 'save file' the definite action on which 
moment you've got rid of the data forever.

Looking at the current filebrowser's functionality, and giving the fact 
that .blends are just like directories too, I would recommend to first 
stick to expending the current filebrowser with previews for the 
internal data, and for the library data (showing previews when already 
linked, or show names, and visualize 'direct' and 'indirect'). That 
will be mostly compatible with how things work now anyway.

The next big step, a real Asset/Library Manager, then can wait until 
the specs and work has been done on fixing issues with the system 
itself.


-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 12 Jul, 2009, at 22:14, Andrea Weikert wrote:

> Hi William,
>
> William Reynish schrieb:
>> Hi Elubie,
>>
>> Hope you don't mind me posting this on the taskforce.
>>
>> I've been looking over your proposal for a future asset manager space
>> type, located here: 
>> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/AssetBrowser
>>   I promised to give some feedback on this, so here are some comments.
>>
>> The concept of such an area of Blender is a great one, and the
>> functionality this provides is much needed. Currently it's quite hard
>> to keep track of the linked data you're using, it's really hard to
>> relink things, remove links, move things around between files. And one
>> of the simplest things conceptually, deleting data, is sometimes all
>> but impossible in Blender(!), because Blender can only remove data
>> when it has no users, yet there is no easy way of seeing where data
>> blocks are being used.
>>
> I am not sure that deleting datablocks is an issue for the asset
> browser. In my understanding it
> might be better handled in the outliner that shows the contents of the
> current .blend file.
> Maybe the term asset manager is a bit misleading and asset browser 
> would
> be more fitting.
>>
>> These are the two main use-cases I can think of for the asset manager:
>> data management and presets.
>>
>>
> Presets is one part, the other that I saw is Appending/Linking from an
> external .blend file.
>> Now for the actual UI you've proposed:
>>
>> * I like the fact that you have the same basic structure of a source
>> list on the left and a content area of the right, shared by other
>> editors in Blender
>>
>> * Previews will make it very easy, fast to recognize items. This is a
>> no-brainer for materials and textures, but would be fantastic if this
>> could work for any type of data - meshes, curves, even animation data?
>> (Not easy!)
>>
> Previews for meshes, curves and other datablocks is planned, though
> needs a bit of research on my part.
>> * I like the idea of auto-discovery by inputting just a path, and
>> Blender then simply aggregates all the data from Blend files in that
>> path. Could even eventually work for things on networks, online(?)
>> Similarly that these library links are not saved in the individual
>> blend files, but accessible from any file.
>>
>> * I'm not sure, but judging on the mockups it seems there is no way of
>> interacting with data that's already inside the current blend file?
>> Perhaps you envisage this asset manager to only deal with linked data,
>> or do I misinterpret? I think it would be quite vital to manage the
>> data that's already in the file, for reusing assets from the same
>> file, for deleting data - all the management stuff.
>>
> I saw that in your mockup you added an additional current file entry. I
> forgot that in my mockup,
> good catch, this was in my plans too ;) For the data inside the .blend
> file I think a litle bit of
> thinking is still required as to what functionality should be provided
> and how it could work.
>> * I don't understand the Groups region. Is it for actual Blender
>> groups, or is it more like a favorites list? It seems like it's a way
>> to group library blends. If so, why have two source lists, one grouped
>> and one not? IMO it'd be a little simpler, cleaner to just have one
>> source list, where you can add folders (not folders in the file
>> system) for grouping items if you wish.
>>
>>
> The Groups region was meant to just group the .blend files so they'd be
> easier to find.
> I do like your suggestion of just adding folders below he Library much
> better though.
> The add folder button should work nicely too.
>> * I think if you have that much data, from many many blend files in
>> one list it's quickly going to get very long ;) Therefore the
>> filtering options are important. The data type filter at the top makes
>> it quick to see only materials, only textures etc (You almost always
>> know what *type* of data you're looking for) but only if the buttons
>> are mutually exclusive. Holding shift can always be used for enabling
>> multiple data types if desired. Additionally, it'd be great to get a
>> search field too (can be on top right, next to the filter). Hopefully
>> this will get implemented in the Outliner too.
>>
>>
> Yes, search field is a great idea.
>> *Using the little arrow to move files into the Groups pane is a little
>> clunky. Perhaps could use the new drag n drop API to move to folders?
>>
>>
> Agreed. It was also meant as an intermediate solution until we have the
> drag n drop API.
>> I've edited your mockup slightly (hope you don't mind!) to clarify
>> some of the points. Added a 'current file' item in the source list,
>> search field, combined the source lists, added New Folder button:
>>
>> http://www.reynish.com/files/blender25/asset_manager.png
>>
>>
> No, on the contrary, good work on completing the stuff I missed. If
> you're ok I'll add your mockup to the
> wiki then.
>
> Cheers,
> Andrea
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>