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

[Bastien Montagne]

Hey Francesco :)

Yes, option 1 is basically allowing to have assets not as full 
datablocks, but as a subset of a datablock. In a very primitive way for 
now (i.e., having filepaths [of images, sounds etc.] of a 'real' local 
Blender datablock controlled as assets).

This was started when I wanted to add a quick second asset engine to my 
branch, using same system as Sybren's work to serve textures from the 
Cloud. Wanted to test a real-life remote server-based system, and 
realized that the addon only gave access to image files, not image 
datablocks! ;)

I think this could be a basis for more advanced sub-datablock 'proxy' 
thing (also very similar to what Lukas proposed some times ago iirc). 
But I do not intend to create a complete system for that now - rather a 
quick workaround/hack for file-based data in Blender, a full design here 
would be worth its own project. Could be enough though to add support 
for things like alembic caches later, hopefully. ;)

And also I was a bit depressed by option 1 when I wrote the mail (will 
imply a lot of noisy monkey-coding changes in our codebase :/), I still 
prefer it to option 2, for pretty much the same reasons as you. Much 
better to keep asset/library handling in a few, generic places, than 
starting spreading it everywhere!

Regards,
Bastien

Le 04/07/2016 à 16:44, Francesco Siddi a écrit :
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers