Content Browser Data Source Implementation Questions

Development Pipeline & Plugins
, ,
1

We are in the midst of creating our own UContentBrowserDataSource that is driven by database calls and could definitely use a bit more information on how the current system is designed. We’ve been able to create folders on demand from that reflect the contents of the database but doing so has been a tedious process of failed attempts. So far it seems like the Navigation Bar, SPathView, and SAssetView all react to different updates paths yet are dependent on each other. Is there any documentation we can reference?

We had a few questions around the implementation of the Content Browser Data Source. As recap: given that we have thousands of products and millions of versions, our assets have to live outside of Unreal, and only loaded or imported as-needed. As such, we’d like to implement a way to access this database through our own Content Browser Data Source (CBDS). The goal is to be able to progressively cache various paths and assets (lightweight asset data, not actual assets unless the user initiates an import), and to be able to access the data in various ways, from asset pickers, SNavigationBars (for picking publish contexts, for instance), and others. As we’ve started to implement it, we’ve encountered a few bumps in the road:

1) Async updates to SNavigationBar

When encountering a new directory that we haven’t fetched yet, we’re able to utilize QueueItemDataUpdate(FContentBrowserItemDataUpdate::MakeItemAddedUpdate()), which allows us to populate the directory once we hear back from the database. However, it doesn’t look like SNavigationBar listens to these updates. How might we update the search suggestions in an asynchronous manner?

2) Support for non-recursive behaviors from a database source.

It seems as though the Content Browser wants to discover all assets and virtual folders when the CBDS starts up, whereas we would only like to surface specific paths as the user navigates through the database tree. It’s been a bit unclear as to what each of the Enumerate calls are intended for. The various Enumerate calls seem to trigger back to back, and often multiple times in a row. As the user navigates the database, or pastes in a path, we should be able to update our local cache which the various enumerate functions trawl.

3) Access to SAssetSearchBox for filtering items with no FAssetData

We’d like to be able to extend the functionality of SAssetSearchBox so as to also query the database for folders or products, so that the user can search the database directly in a seamless manner (this would mean our CBDS implementation could provide search result items that haven’t been cached yet). Is there a way to capture the text in the search box, or at the very least receive a string given a query key? If there’s no way to get at that search box, is there a way to customize the Content Browser’s AssetView to add our own search box?

2

Hi Jackson,

I’m not surprised that you are having a bit of a hard time there. If I may be honest while the data source system was designed with some extensibility in mind,

it wasn’t made to be easy or quite flexible as it was mostly driven by some incremental needs from inside Epic.

In its current state the Content Browser is not set up at all to be friendly with the concept of a remote data source.

We don’t really have doc but here is the gist of how that system works.

The content browser asset data source subsystem acts as a sort query source that multiple widget can query for some information.

Most of these widgets assume that the content is local and the data/current state can retrieved immediately.

Each of these widget will also generally have its own copy of the state via its own list of content browser items.

For a few examples of widgets there is the SPathView, the SNavigationBar the SAssetView and the various asset pickers, but others licensees and plugins can also bring their own.

While some widgets do support incremental updates, those were more made in a way to reflect that the data may change while the view is active rather than being made to support on the fly discovery of the content.

The widgets of the content browser tab are all independent but do sync their state together via some events at the level above. This is mostly done in the SContentBrowser widget.

Ok so now with that out of the way, I’m not suggesting that you don’t go down the path of the content browser data source to integrate your database but I just wanted to give you a heads that you will need to do some engine modifications to achieve this.

For the sub questions, here are my suggestions,

  1. I don’t think updating the suggestion combo box is a good UX there, I would probably suggest that you notify the data sources of what is being typed and let them try to precache the virtual paths for that input, once the typing delay is expired just provide what you have at that time. (See SNavigationBar::HandleTextChanged)
  2. Your assumption is right some widget like the path view will try to fully populate itself when created, the same will happen on a recursive search in the asset view. I don’t think on our side this is something we will fully support but you could add some contextual object to the filter creation and compilation to help your data source know when it’s ok or not to cut the recursive search early. I suggest putting a break point in the CompileFilter function of your data source to track the call sites. Then look at the callstacks to find where the widget creates the filters.
  3. At the moment, not without an engine change, this is not something we want to expose for now. You can put a break point in SAssetView::OnFrontendFiltersChanged or take a look at SAssetView::Construct to see where the view reacts to a change in the search box.

Sorry this is probably not the answer you were hoping for, but I hope it will still help you and your team.

Pleasure,

Julien.

3

Hi Julien,

Appreciate the response. We’ll dig into those suggestions as we explore how we integrate our asset database with Unreal, and thanks for the general overview.

(But also, just as feedback, we’d love to see some generic API support for external / remote data sources come to the Content Browser someday.)

Best,

Jackson

4

It’s definitely something on our radar but it’s to soon to say we are committed to it.

Best,

Julien.