[Bf-committers] How to handle simple files (images, videos, sounds, fonts...) as Assets?

[Francesco Siddi]

Hi Bastien,

Thanks for sharing your thoughts on this! 

After a chat with Pablo at the BI, here are come questions and considerations.
What is the main reason to introduce this feature? It would help to understand what brought you to the current 2 options.
One of the first things we think about when considering non-blend asset linking is Proxy/LOD (it's one of the recurrent limitations we run into when dealing with complex scenes).

If option 1 creates some sort of additional layer between existing data blocks and file representation (possibly using something more than just a path, like file version and variant) then it's very interesting. 

I guess this is achievable also with option 2, I just don't know if it would make sense internally. From a scripting/tools perspective, having all external dependencies available under one library type (instead of scattered across extended data blocks, like would happen with option 2) would provide a good overview of such dependencies for further processing.

Looking forward to discuss this further, maybe with a "use case" approach.

Cheers,
Francesco

On 2 July 2016 at 17:13:59, Bastien Montagne (montagne29 at wanadoo.fr) wrote:

Hey guys & girls,

One of my most recent work in asset-engine branch has been to try to  
introduce mere non-blend files as assets (pictures, sounds, etc.), but  
am facing some serious issues/questions there…

I think it's pretty obvious why we need some kind of asset handling for  
those files - even current Cloud addon in blender only gives access to  
texture files, not texture datablocks.

I can imagine two ways of implementing this in Blender currently:
I) Adding a new 'type' of library (called virtual library so far), which  
has an empty path, and is only there to materialize related datablocks  
as 'lib' ones, and store asset engine references.
II) Adding some extra, asset engine reference type of data to datablocks  
which are based on those files (Image, Text, MovieClip, Sound, etc.).

Option I), which I started to implement in asset-engine branch, is  
rather easy to add - as long as we accept to keep the datablocks  
behaving as 'really' linked ones, that is, to keep them non-editable and  
consider them as mere linked data (with some trick in read/write code to  
actually write datablock itself, and not the usual 'ID' one we use for  
linked data). But I do think we’d want those datablocks to be editable,  
and there comes the problem. Basically, we use `id->lib` as simple test  
everywhere in Blender to detect libblocks, and apply to them specific  
rules (like being non-editable etc.). Having 'virtual' libraries related  
to 'real' datablocks would mean changing this check all over Blender  
codebase, which I'm not totally fan of.

Option II) would mean we kind of put some asset handling code outside of  
pure generic ID/Library area, would be a second, parallel asset handling  
code. Find this even worse solution.

But in both cases, am afraid we end up with some even more complicated  
library handling - and it’s already not the simplest and sanest part of  
Blender… So would love to get your feelings, ideas and advices!

Cheers,
Bastien


_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
https://lists.blender.org/mailman/listinfo/bf-committers