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