Asset Browser: Add pre+post handlers to asset drag & drop #113658

Greg Zaal · 2023-10-13T11:58:32+02:00

Greg Zaal commented

2023-10-13 11:58:32 +02:00

This is intended for add-ons to be able to hook into the drag & drop event and run additional code to augment the default behavior when dropping assets from the asset browser.

For example, with our Poly Haven add-on, we have a number of feature requests which depend on this functionality:

Downloading texture files and dependencies on-drop, rather than up-front when installing the add-on.
Let the user change the texture resolution of imported assets
Copy settings from previous assets if the user is replacing it (e.g. retain texture scale when changing between different brick textures, or match HDRI exposure)

Implementation notes:

This is my first PR :)

I'm unsure if my changes to the return WM_file_append_datablock... blocks and BLI_assert_unreachable are the right approach, but it seems necessary here to avoid returning early so that we can run the handler after appending and then return the result after.

This is intended for add-ons to be able to hook into the drag & drop event and run additional code to augment the default behavior when dropping assets from the asset browser. For example, with our [Poly Haven add-on](https://github.com/Poly-Haven/polyhavenassets), we have a number of feature requests which depend on this functionality: 1. Downloading texture files and dependencies on-drop, rather than up-front when installing the add-on. 2. Let the user change the texture resolution of imported assets 3. Copy settings from previous assets if the user is replacing it (e.g. retain texture scale when changing between different brick textures, or match HDRI exposure) # Implementation notes: This is my first PR :) I'm unsure if my changes to the `return WM_file_append_datablock...` blocks and `BLI_assert_unreachable` are the right approach, but it seems necessary here to avoid returning early so that we can run the handler after appending and then return the result after.

❤️ 1 🎉 2

Greg Zaal added 1 commit 2023-10-13 11:58:43 +02:00

d1921b4f2b Asset Browser: Add pre+post handlers to asset drag & drop

Dalai Felinto requested review from Campbell Barton 2023-10-13 15:06:52 +02:00

Dalai Felinto requested review from Julian Eisel 2023-10-13 15:06:52 +02:00

Dalai Felinto added this to the Pipeline, Assets & IO project 2023-10-13 15:07:05 +02:00

Julian Eisel commented

2023-10-13 17:49:06 +02:00

Much needed feature! Great to see you work on this!

I know that studios also really want this, to do post processing of imported assets which is often crucial for pipeline tools to work. @Mets could you give us a specific example from the Blender Studio?

It seems incorrect to me to only do this for assets. While this may be the more desired way to import assets nowadays, what about regular link/append? Otherwise studios would have to use the asset browser to ensure their tools keep working, and wouldn't be able to use regular link/append anymore.

@mont29 @ideasman42 I've also wondered in the past if there is a particular reason why this is not there yet? I know it's an often requested feature from studios.

Much needed feature! Great to see you work on this! I know that studios also really want this, to do post processing of imported assets which is often crucial for pipeline tools to work. @Mets could you give us a specific example from the Blender Studio? It seems incorrect to me to only do this for assets. While this may be the more desired way to import assets nowadays, what about regular link/append? Otherwise studios would have to use the asset browser to ensure their tools keep working, and wouldn't be able to use regular link/append anymore. @mont29 @ideasman42 I've also wondered in the past if there is a particular reason why this is not there yet? I know it's an often requested feature from studios.

❤️ 1

Bastien Montagne removed this from the Pipeline, Assets & IO project 2023-10-13 18:16:31 +02:00

Bastien Montagne added the

Module

Pipeline, Assets & IO

label 2023-10-13 18:16:43 +02:00

Bastien Montagne commented

2023-10-13 18:19:15 +02:00

Having handlers around link/append in general would make total sense to me yes. I guess it's 'just' that nobody did it?

Bastien Montagne commented

2023-10-13 18:21:04 +02:00

But isn't the 'append/link pre/post handlers' topic different than the 'drag-n-drop pre/post handlers' one? Imho they would have different covering of cases (and therefore be complementary)?

Julian Eisel commented

2023-10-13 18:27:36 +02:00

What's described here doesn't seem to be tied to drag & drop really, more to importing.

Also worth considering: Should this run when temporarily importing data-blocks? We have the feature to import data-blocks nowadays temporarily, without adding them to the current file's Main. Useful for example for poses, where we import an action, copy its parameters to another action, and throw it away again. Same with the upcoming brush assets. Or to easily remove the data-block again if using it failed in some way.

What's described here doesn't seem to be tied to drag & drop really, more to importing. Also worth considering: Should this run when temporarily importing data-blocks? We have the feature to import data-blocks nowadays temporarily, without adding them to the current file's `Main`. Useful for example for poses, where we import an action, copy its parameters to another action, and throw it away again. Same with the upcoming brush assets. Or to easily remove the data-block again if using it failed in some way.

Greg Zaal commented

2023-10-13 18:42:14 +02:00

In my case I prefer to hook into asset drag & drop, but adding handlers for link/append as well (or instead) seemed to be fairly trivial. I already tested this before finding the right methods for the asset browser specifically.

Julian Eisel commented

2023-10-13 19:03:30 +02:00

In my case I prefer to hook into asset drag & drop

What's the reason for that?

> In my case I prefer to hook into asset drag & drop What's the reason for that?

Jesse Yurkovich added this to the Render & Cycles project 2023-10-13 19:38:37 +02:00

Jesse Yurkovich removed this from the Render & Cycles project 2023-10-13 19:39:17 +02:00

Demeter Dzadik commented

2023-10-14 02:55:03 +02:00

Great to see someone working on this indeed, I've been asking for this since I arrived in Amsterdam in 2019! 😅

Our use cases (all post-handler):

Streamline linking+instancing/overriding of assets to a single drag&drop.
Implement our own "restricted override" idea, just at a per-object level, by making it so that in our rigged assets, only Armature objects become editable overrides, and nothing else.
Execute scripts that may be attached to assets without having to go into the text editor or save+reload the file. Such scripts might:
Register boatloads of rig UI
Register new shortcuts
Apply render settings

Imaginary use case for pre-handler:

Summon a pop-up before loading the asset, to choose a variation or color, for an asset where you would have to do that every time anyways. Not exactly sure if this would actually be possible though, you gotta store the data in some awkward, permanent place, since you don't have an operator to store it on.

Suggestions (sorry):

Separate handlers for the linkappend operator and drag&drop would be the most flexible. I would register to both, but maybe not everybody would.
I think it might be crucial to give the handlers useful parameters: The ID that just got loaded should be available from at least the post handler. And in the pre handler, maybe the .blend path and ID name, if the ID itself is not yet available.
If we were to raise an exception from the pre handler, would that prevent the linkappend? I think it might be useful if it did, but that may not be consistent with how handlers work in general.
I wonder if both bpy.ops andbpy.data.libraries.load() should trigger the handlers. I think it would be nicer if the latter didn't, but I guess that might be confusing. In any case, at least those behaviours should be conscious decisions in this PR.

Great to see someone working on this indeed, I've been asking for this since I arrived in Amsterdam in 2019! 😅 Our use cases (all post-handler): - Streamline linking+instancing/overriding of assets to a single drag&drop. - Implement our own "restricted override" idea, just at a per-object level, by making it so that in our rigged assets, only Armature objects become editable overrides, and nothing else. - Execute scripts that may be attached to assets without having to go into the text editor or save+reload the file. Such scripts might: - Register boatloads of rig UI - Register new shortcuts - Apply render settings Imaginary use case for pre-handler: - Summon a pop-up before loading the asset, to choose a variation or color, for an asset where you would have to do that every time anyways. Not exactly sure if this would actually be possible though, you gotta store the data in some awkward, permanent place, since you don't have an operator to store it on. Suggestions (sorry): - Separate handlers for the linkappend operator and drag&drop would be the most flexible. I would register to both, but maybe not everybody would. - I think it might be crucial to give the handlers useful parameters: The ID that just got loaded should be available from at least the post handler. And in the pre handler, maybe the .blend path and ID name, if the ID itself is not yet available. - If we were to raise an exception from the pre handler, would that prevent the linkappend? I think it might be useful if it did, but that may not be consistent with how handlers work in general. - I wonder if both `bpy.ops` and`bpy.data.libraries.load()` should trigger the handlers. I think it would be nicer if the latter didn't, but I guess that might be confusing. In any case, at least those behaviours should be conscious decisions in this PR.

Greg Zaal commented

2023-10-14 10:18:19 +02:00

In my case I prefer to hook into asset drag & drop

What's the reason for that?

In our case we care only about drag & drop from the asset browser, not general append/link from other places. I feel there's likely to be unintended behaviors, now or in the future, if we hook into append/link rather than drag/drop.

If a user is simply appending data from the file menu as normal, I would say they don't expect (or want) any special behavior from an add-on to invade the process, even if this file they are appending from happens to be inside an asset library. Rather the expected behavior from an add-on that creates and manages an asset browser library should remain isolated to the asset browser UX only.

It's not a train smash to have only an append/link handler, but I feel there are likely more possible use cases for having drag/drop handlers as well that might not have that much to do with append/link that we haven't thought of.

Sidenote: Maybe general drag/drop handlers (e.g. to catch dropping files/URLs from outside Blender) are more helpful too? E.g. to auto-detect which format importer to use, or to allow dragging URLs from a browser for some download & import behavior. Maybe this is offtopic :)

> > In my case I prefer to hook into asset drag & drop > > What's the reason for that? In our case we care only about drag & drop from the asset browser, not general append/link from other places. I feel there's likely to be unintended behaviors, now or in the future, if we hook into append/link rather than drag/drop. If a user is simply appending data from the file menu as normal, I would say they don't expect (or want) any special behavior from an add-on to invade the process, even if this file they are appending from happens to be inside an asset library. Rather the expected behavior from an add-on that creates and manages an asset browser library should remain isolated to the asset browser UX only. It's not a train smash to have only an append/link handler, but I feel there are likely more possible use cases for having drag/drop handlers as well that might not have that much to do with append/link that we haven't thought of. Sidenote: Maybe general drag/drop handlers (e.g. to catch dropping files/URLs from outside Blender) are more helpful too? E.g. to auto-detect which format importer to use, or to allow dragging URLs from a browser for some download & import behavior. Maybe this is offtopic :)

Greg Zaal commented

2023-11-16 08:37:37 +01:00

Congrats on the 4.0 release :) Any chance we can try to get this patch into 4.1? It'd be great if we could include these improvements in the next update of our add-on.

I think the discussion on whether to also add append/link handlers and generic drag+drop handlers (from outside Blender) is separate and doesn't block this implementation.

Congrats on the 4.0 release :) Any chance we can try to get this patch into 4.1? It'd be great if we could include these improvements in the next update of our add-on. I think the discussion on whether to also add append/link handlers and generic drag+drop handlers (from outside Blender) is separate and doesn't block this implementation.

Thomas Dinges commented

2024-01-09 10:26:43 +01:00

@JulianEisel @ideasman42 Hey, can you please follow up on this for 4.1? :)

Demeter Dzadik commented

2024-02-23 14:59:50 +01:00

This would be so good 🙏

❤️ 2 🚀 2

Laurens-Corijn commented

2024-03-27 16:26:49 +01:00

First-time contributor

Very much waiting for this, the lack of many handlers and callbacks is really a big miss for Blender Addon development!

❤️ 2

CynthiaDarrow commented

2024-04-04 02:56:04 +02:00

First-time contributor

Hi, Cindy here,
I am blender user for my short film project. I have a difficult time on large environments because my RTX3080 card has 10gbs of memory. I wrote Greg, from polyhaven.com, that I was confused by his asset browser addons that contained LOD 0,1,2,3 inside a single instance. In my project I made such instances real, and then separated out the LOD I needed, (so as not to burden my graphics card).
Greg replied that he knew this was a big problem, and that a patch he submitted 6 months ago would allow the user to select the correct LOD version from the asset browser BEFORE dragging into a blender project. This would greatly help users with limited computer graphics cards, like me. I appreciate the amount of work all blender developers have on their plate and I love version 4.0. If any developer can spare the time, please look at this change for addons.
Thanks again for making Blender for all of us!
Cindy

Hi, Cindy here, I am blender user for my short film project. I have a difficult time on large environments because my RTX3080 card has 10gbs of memory. I wrote Greg, from polyhaven.com, that I was confused by his asset browser addons that contained LOD 0,1,2,3 inside a single instance. In my project I made such instances real, and then separated out the LOD I needed, (so as not to burden my graphics card). Greg replied that he knew this was a big problem, and that a patch he submitted 6 months ago would allow the user to select the correct LOD version from the asset browser BEFORE dragging into a blender project. This would greatly help users with limited computer graphics cards, like me. I appreciate the amount of work all blender developers have on their plate and I love version 4.0. If any developer can spare the time, please look at this change for addons. Thanks again for making Blender for all of us! Cindy

👍 1 ❤️ 1

This pull request has changes conflicting with the target branch.

source/blender/blenkernel/BKE_callbacks.h
source/blender/windowmanager/intern/wm_dragdrop.cc

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u asset-drop-handlers:GregZaal-asset-drop-handlers

git checkout GregZaal-asset-drop-handlers

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Asset Browser: Add pre+post handlers to asset drag & drop #113658

Implementation notes:

Checkout