Asset Browser - Hide and show engine assets

[lsemp3d]

As a user, I need the ability to occasionally turn on (toggle switch) and see my engine assets from inside the Asset Browser. By default, we should hide any assets and folder if they can't be used (in their current state) within their project. These files can make the Asset browser feel very noisey for our customers, and there is very little value for customers seeing this data on a daily basis. We should also set this setting to be the default for most people.

 

The specific files or folder we can hide from user are as followed.

• intermediate assets,
• etc.

 

[rainbj]

@lmbr-pip, @AMZN-stankowi. We just started on this task of putting a toggle in for hiding engine related assets. Any specific file extensions or types you can call out to help us hide behind this flag would be very helpful. Please note this is a toggle meaning the user can turn this back on at any point.

The user statement we want to use here is. "As a user, I don't want to see any assets in my asset browser that I cannot use directly in my level." This doesn't mean by some association we can use it. It means I can directly use it when creating my level.

Please note that I suspect we could be more restrictive at first, and then decided to remove restrictions as we learn more. Also note that this restriction will not interfere with any modal windows that pop up and ask the user to directly pick a specific file.

[AMZN-stankowi]

I'd like to get the terminology cleaned up, first. We already use the term "engine assets" elsewhere to mean something different than what this pull request intends to manage.

We don't want to hide intermediate assets, those are useful and can be any asset type. We just need to prevent people from writing changes to intermediate assets or creating new assets in the intermediate assets folder. If intermediate assets are hidden, it will make the feature hard to use.

[rainbj]

Offline conversation:

rainbj

• The idea should be that these assets should be behind a simple flag, so we can clean up the list as we go along. We should do just a first pass on clearing out asset we all know are not useable and then make the call on hard assets. Example anything AZ- related shouldn't be seen when this flag is on. FYI, I wouldn't consider "intermediate assets" an "engine assets". Engine assets are assets, that are only useful to the engine.

AMZN-stankowi

• Yeah, that parts not a big deal, I just wanted to make sure we pick a better name (we already use "Engine Asset" for something else) and I was pointing out we shouldn't do it for intermediate assets. Also, technically some of the product assets you want to hide aren't actually generated/used by the engine, they're generated & used by Gems

rainbj

• This might technically be true, but, to the user. I see them grouping their data into two groups, my stuff and your stuff. Your stuff would be anything that came from the engine that I can't instantiate in my project, or even if I could. I shouldn't be using. And then just everything else the user cares about.

AMZN-stankowi

• gotcha, well we still use Engine Assets in two other ways right now, and this would be a third, different way which I feel would be even more confusing.

rainbj

• I hear you on that

AMZN-stankowi

• so calling them "Non-Instantiatable Assets" or something would be cleaner.

rainbj

• Let me do this. Let me pull docs @sptramer in and see if they can help us here with the naming.

[sptramer]

Maybe what we want are 3 types of assets a user can filter on:

• Core asset - Asset required by the engine itself to function
• Gem asset - Asset provided by a Gem (named in the log message somewhere)
• Project asset - Asset provided by a project / the user

Then there's also the 4th type of asset, "Sub-asset" or "Intermediate asset" which are the items displayed in the tree underneath a main item (which I would recommend be collapsable). So we could get a hierarchy something like:

▶Core Assets
  ▶<Processed engine-ready asset>
      <Intermediate assets>
      ...
▶ Gem Assets
  ▶ <Gem name>
    ▶ <Processed asset>
      ...
▶ Project Assets
  ▶ ...

This keeps assets separated out into 3 categories for easy debugging and traceback of ownership.

[micronAMZN]

TLDR - My preference would be to allow me to specify the asset directories I care about to be displayed/searched by Asset Browser. Hide product (runtime) assets I can't instantiate or reference in a component, but list them in the details pane or some sort of right-click info menu.

In my Asset Browser:

• o3de/Assets - These are assets that are part of the engine and used by the engine and editor. Fonts, scripts, and many legacy assets that may or may not be used by the engine. I am not interested in these assets as a user. The only asset here I might use in a project is the Open Sans font. I think this entire structure should be hidden by default, and shouldn't return search results by default either.

• o3de/Gems - All the Gems included with O3DE. There are some assets in here I am interested in using, but they are sometimes buried deep in a directory structure. The preset PBR material types, for example, are like 8 directories deep. There are also a lot of assets in here used for tests that could be instantiated, but aren't useful. For Gems in general, I think it'd be useful to put all the assets and only the assets intended for users in the <GemName>/Assets directory so they are easy to find. Assets used internally by the Gem or for tests should go in <GemName>/Code/Assets or some other standardized directory that can be easily filtered out from Asset Browser and search results.

• o3de/registry - .setregs. Not interested in seeing these in the Asset Browser.

• Projects/ - There's a whole list of subdirectories here, and there's all sorts of files showing in asset browser including setregs, cfg and json project configuration files. The only directories I care about in the context of Asset Browser is the assets in my Assets directory or potentially other directories I create.

Sub Assets

If you look at an actor, for example, You'll have the root FBX, and beneath it the actor asset, which is what you reference in the actor component, and several additional assets each representing some set of vertex properties that the actor has, mesh, skin weights, colors, UVs, LoDs, etc.

My understanding is that these all used at runtime, so it might be more appropriate to call these runtime assets. We've been referring to these as product assets in the docs.

Most artists or TDs will probably intuit "intermediate asset" to be the FBX file, which is what we've been referring to as a scene source asset in the docs.

Although it's a bit much to display all these assets in the Asset Browser, it's handy to know they have been generated. Perhaps Asset Browser only shows the assets that can be instantiated or referenced by a component, but displays the full list of product (runtime) assets in the details pane or some right-click info menu.

[AMZN-stankowi]

To move forward on this, I think we can break content down into a few categories:

1. Content (Source Assets and Product Assets) used by the Editor or other Engine logic and not really intended for use by a content creator working on a project. There's usually no harm if someone does use it as so, but these sorts of files aren't particuarly interesting to content creators. Example: https://github.com/o3de/o3de/blob/development/Assets/Editor/Icons/RotationWarning.png this is used by the Editor as a warning icon for an interface, it's unlikely a game team content creator would ever want to re-use this icon on game content, so hiding the Source Asset and associated Product Assets by default would make a lot of sense.

2. Product Assets that are automatically referenced by other content and rarely directly used by content creators in the Prefab Editor in the Editor or other Editor tools (Actor Editor, Material Editor, etc). These are files that are rarely directly used in Prefab editing or other workflows in Editor.exe, so hiding them by default makes sense. An example of a file that matches this logic is mipmap product assets for image files, like in this example image. These mipmaps will be loaded and referenced when necessary by 3D content for rendering textures, but there is rarely a need for a content creator to think about or use a mipmap directly.

4. Product and Source Assets that are useful to content creators in tools besides the Prefab Editor but have no direct use in the Prefab Editor. Editor.exe is a monolithic application that contains separate workflows for interacting with files in different ways, and it can often be confusing to people using one workflow why they see content that's intended for use in another workflow. This is one place I would want to be cautious about making any major changes in hiding content, because while a piece of content may have zero value to someone editing a Prefab using functionality in Editor.exe for editing Prefabs, it may be useful for someone using a different editing workflow in Editor.exe, like the Material Editor, Animation Editor, etc. However, if we decide that the Asset Browser is primarily a tool for Prefab Editing and the other editors aren't expected to interact with the Asset Browser, then I think it's safe to hide that content in the Asset Browser.

5. Source Assets with a single Product Asset, that are expected to always have a single Product Asset. We already hide these for some file types, like JSON. We could expand this to other file types, like Lua, to ease confusion here. See this example where project.json does not have a foldout to view product assets because it's a single Product Asset and there's no reason to, but test1.lua does have a foldout to show the Product Asset.

6. Non-descriptive, multi-use file formats. These are a challenge because there is often not an immediate hint to when and how these should be used. For example, if a team has a component that uses a settings file with a json extension to control how the component functions, they will want to see those relevant json files in their Asset Browser. However, if they used the json file extension on this file instead of a more descriptive file extension, it can be challenging to figure out which files are relevant to those workflows and should be shown, versus which files should be hidden. I don't have a great solution here we can apply globally, my feedback to teams building systems is to use file extensions that match the usage of a file and not the format of data in the file itself, so instead of "MyPlayerSettings.json", use "MyPlayer.gamesettings" or something.

7. Content types shipped as part of the core O3DE repo, versus content types enabled via extensions, either downloaded from elsewhere or created internally at a studio. We'll want to make control of what's hidden or not hidden from the Asset Browser data driven, ideally through multiple files like setreg files, so teams can make use of the engine default content hiding list, and then write a custom extension to hide custom asset types unique to their project.

8. Complex source assets with several product assets that are useful in different ways. Scene files, like FBX files, fit this really well. An FBX file can effectively have unlimited product assets of several categories: procedural prefabs, materials, animations, static geometry, skinned meshes, physics meshes, debug scene graphs, azbuffers, and other custom product assets that a team builds for themselves. Some of these are content types we can more obviously ignore (azbuffers don't have any direct workflows associated with them and are instead used by azmodels, so we could hide buffers by default safely), while others are more challenging (people are confused by the additional azmodels generated for procedural prefabs, but these additional models are actually still directly useful and once a content creator gets past that learning curve, they may want to see and interact with these product assets while continuing to ignore other product asset types, like buffers.

So a complete solution to handle all cases I think would take some time to design and build. My suggestion is we build an Asset Type Tagging system (not to be confused with an Asset Tagging system), that allows builders to include meta information, such as a tag, for asset types supported by the builder. The Scene Builder could apply the "Useful For Prefab Editing" tag to the azmodel asset type, and the "Hide From Basic Workflows" tag to the azbuffer asset type, for example. Then the Asset Browser could be configured with a default set of asset type tags to visualize, hiding anything not matching the filter, with user and team control over adding/removing tags from local or team filters, so people can customize what they see.

However, if we're looking for a really simple next step, my recommendation would be to make a few assumptions: 1) The Asset Browser is primarily useful for Prefab Editing. 2) The 80% use case is people really just want to see the file types they can drag and drop into the 3D viewport or Entity Outliner. With those assumptions, we could have a toggle on by default in the Asset Browser "Just show source assets that support drag and drop, and only show product assets that match the default drag and drop filter target for a source asset". The result of this is, for say FBX files that contain a procedural prefab, it would only show that procedural prefab and nothing else. The benefit here is it would also make drag and drop predictable, right now due to the complexity of drag and drop and our lack of pre-visualization on drag and drop, people often get unexpected results dragging a source asset into the outliner or viewport.

My understanding is that these all used at runtime, so it might be more appropriate to call these runtime assets. We've been referring to these as product assets in the docs.

Our terminology here is Product Asset for these. Source Asset (FBX file, PNG, etc) is the starting point (for the Asset Processing pipeline, but not for that piece of content, which probably came from a Blend file or PSD).

Not all Product Assets are used at runtime, some are debugging or Editor only, so I don't think it would make sense to rename them to runtime.

Most artists or TDs will probably intuit "intermediate asset" to be the FBX file, which is what we've been referring to as a scene source asset in the docs.

Intermediate Assets in our terminology are Source Assets output from another job, that themselves are not functionally Product Assets (while technically they are Product Assets due to how they are created, they aren't really available for use as Product Assets to other systems). The difference here is that Intermediate Assets are read-only to anyone else, but otherwise they are identical to any other Source Asset and will themselves generate Product Assets. Intermediate Assets can be any asset type, I've written a custom builder that reads an SVG file and outputs an FBX as an Intermediate Asset, which then gets processed by the Scene Builder to make the standard scene product assets (procedural prefab, mesh groups, materials, etc).

[rainbj]

Perhaps Asset Browser only shows the assets that can be instantiated or referenced by a component, but displays the full list of product (runtime) assets in the details pane or some right-click info menu.

@micronAMZN To some of your question above, I wanted to let you know we do have a design coming for this, and it's already in the backlog. The new Asset Browser will have a new Asset Browser inspector panel on the right side of the screen next to the entity inspector panel. Eventually, merging both of these panels together, becoming a context aware selection tool. But for now, they need to be two panels to get started. You can see the designs here - https://github.com/o3de/o3de/issues/12857

[rainbj]

@lsemp3d I didn't see this when I tested latest.

[dtamkin1]

@rainbj You need to toggle on the WIP asset browser console variable to view these changes

[rainbj]

@dtamkin1 I do have the switch toggle on, and I was poking around looking for this setting, but I could find it. Does this set of work has it own flag?

[rainbj]

@dtamkin1 thanks! We saw this one today during the UX review. A couple small issue we called out here. 1) Procprefabs should be excluded from this list. 2) This toggle shouldn't remove the expand arrow from all assets in thumbnail view. 3) The primary purpose behind this list it to hide asset that the engine needs, but not hide asset that humans would need. So this might require creating a list of asset we should hide and then we can send it around to the group to get buy in. Thanks!

[ghost]

From UX review: we need to verify in a more current build that procprefabs are be excluded from this flag. It looks like they are still being excluded by default and they shouldn't be. There are also notes on this ticket about naming and maybe breaking this tag down a little more granularly

Reopening due to work not being complete.

[dtamkin1]

Hi @rainbj, all asset browser entries are of type folder, source or product. Currently, the toggle is filtering out all product files.

To start with implementing a more specific filter, it would be helpful to have a list of file entry types and files that we would like to filter. For example, something like "filter out all product assets with the following extensions: .streamingimage, .imagemipchain, .azbuffer, .azmodel, ....etc" or even the opposite, "filter out all product assets that do not have the following extensions: .procprefab, etc" and along with that list (or various lists) the name we should use for the groups

Other than by file extension, a way to implement this would be with a tagging system, but a tagging system would take time to design and build.

[rainbj]

Hi @dtamkin1 I would agree your first pass of file restrictions of ".streamingimage, .imagemipchain, .azbuffer, .azmodel". However, I do want to check in with @AMZN-stankowi and @lmbr-pip to verify there are no other file types they know of right off the bat that would be good file types to hide behind this filter flag. If not, then please proceed with the ones above.

I was also thinking about what is the best naming conventions here. @AMZN-stankowi made a good point previously that its actually "engine assets" is not a good encapsulation of what this flag means. Maybe something like "unusable editor assets"? Just an idea. Thanks