So the proposal is to avoid the concept of a single static type. The fact that an asset is an image may not matter much to the user, what the image represents and thus what it can be used for does. What matters most is the object itself, the format it happens to be stored in is irrelevant to a degree.Īn image could be a reference image, a bump map, a stencil texture. How much should it matter to the user if an image is already a Blender data-block or just an image on the hard drive? Or if an object is already native Blender data or will go through an importer after dragging in. Nor does that cover assets that are not IDs (files, USD assets, presets, etc.). So just ID type often isn't granular enough. Is it the ID type? If so, we wouldn't be able to tell apart a compositor node tree from a geometry node tree. Instead, the following proposes a way to define type related characteristics (traits) of an asset, which can then be mapped to precise behavior. Resolving a definite type for an asset is difficult. Loaders may instantiate and use other loaders. Moved to T103188: Asset System: Asset Library Loader.Īll loader methods should be expected to run in a thread. UI project organization (classifying reports, organize workboard, organize meetings, etc.)

Generally the idea is that Harley helps on small, preapproved tasks (which tend to be neglected) falling into the following categories.

Blender free assets library