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 ([email protected]) 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 [email protected] https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
