The critical flaw of asset browsers
Many big editors and toolsets have asset browsers. These browsers allow users to find what they need, and to then either open that asset, or place that asset into a main view with other assets. This can be both in 2D, or 3D. I say ‘many’, because not every Digital Content Creation (DCC) tool has an asset browser, as some rely on Windows’ Explorer, or macOS Finder, for their asset browsing needs. In this post, I am going to focus on integrated asset browsers in 3D toolsets. The flaw and its solutions apply to other asset browsers too though. What is that critical flaw?
Relying only on names for search
When you are asking users to type in names to find the assets they want, you are severely limiting the usefulness of your asset browser. I first publicly talked about this in a talk at GDC 2016, where I played a game with the audience called ‘Name that model’. You can find that in this recording of the talk, starting at 49:30: https://youtu.be/brByJ5EVBn4?t=2970
Let’s go into a few of the problems that make up the issue of exclusively using names for asset search purposes.
Every naming convention is flawed
You will never be able to create a naming convention that pleases every person, and every filesystem out there. Especially Linux is extremely picky about upper and lowercase letters, so if you have not accounted for fuzzy searching upper and lowercase, and are using a Linux server to host assets on, then you already have severe limitations for your naming convention. The names need to be legible to humans, using understandable words and terms, yet also fit the technical needs of the pipeline.
The usual questions will come up: What is the name of a file? Does it please every single part of the pipeline, from outsourcing, to artists, to tools, to import/export, to engine? Do we use underscores to separate name modifiers, like “wood_door_broken”, or do we use dashes like “wood-door-broken”? What if that door can be destroyed, and the splinters need separate models with physics that lie around on the floor afterwards? Do we call those “wood_door_broken_splinter”? What if there are multiple splinters, do we give those different names like “wood_door_broken_splinter_tall”, or do we name them like “wood_door_broken_splinter_1”, “wood_door_broken_splinter_2”? If we number them, do we start at 0, or do we start at 1? How many modifiers of names are allowed, and what if we add a new asset later on that does need more modifiers, are we then allowed to abbreviate 'wood_door_broken_splinter_tall_1’ to 'wd_dr_br_spl_t_1' ?
And what if the asset is a texture, a material, a SFX file, or otherwise not a 3D model? Are assets organized by use, like furniture assets, by material elements like wood and metal, or something else? Do we go for "wood_door" or "door_wood"? And there are a million more questions you can ask.
For example, in the great naming convention video that Masahiro Sakurai did on his YouTube channel, where he talked about the naming convention for fighter moves in Super Smash Brothers, there are no underscores, no dashes, and a lot of abbreviation:
Is this a good or bad naming convention? That is the wrong question. Does it work well enough for their use case? Yes, then by all means keep doing it. His points are correct in that file names and labels need to be easy to understand, that someone looking at them for the first time should know what they are for, and that it is all about finding a balance.
These naming conventions have a huge impact, and create many questions for the asset browser too. For example the Unreal Engine content examples have a barrel that explodes. So when a user searches for ‘barrel’ in the asset browser, should all the little barrel parts also appear? Is that useful for the user, or is that visual noise in 99% of the cases when someone searches for ‘barrel’?
This doesn’t just go for 3D editor asset browsers either. For example, let’s talk about digital store platforms. You’ve probably already seen this yourself when trying to order something online. For myself, I may have bought an item in the past called: “Pitch Black Solid Thermal Insulated Grommet Blackout Curtains/Drapes for Bedroom Window (2 Panels, 42 inches Wide by 63 inches Long, Black)”. That is the full name of the item on the store. Though really, it isn’t a name anymore. It’s just a description as the name, especially when it starts to include the actual measurements. I understand why sellers would write out that name though, as it gives them a better chance to be found among ten thousand other items on sale, so the market will force their hand to do it that way. You have probably seen the same happen with assets in your asset browser, where the names get more and more modifiers to them, just to clarify what something is, and you hope your users find the assets they need through those words.
With all those questions, and many more, you will never reach a consensus that everyone is happy with. You will be able to argue forever on the pros and cons of all of those choices. You will have to make a decision that works with the tech, and pleases the most folks on your team, which is never everyone. You hope to reach consensus with most, and even that is not always possible. This means that whatever naming convention someone is used to, from for example an other pipeline, or an other studio they worked with, isn’t applicable to the next. Every studio will use a slightly different naming convention, and so your users will have to constantly remember and think about what the naming convention for your projects are like. Of course making the search fuzzy enough that if they type “wood splinter” they find the asset called “wood_door_broken_splinter_tall” is a necessary base element, but that brings us to the second issue.
Your users can only remember a limited amount of names
If you have 10000 or more assets, which is not an unrealistic number for a large game if you have 3D assets, textures, materials, etc, then your users will not be able to remember all asset names. If you have 1000 assets, users will not be able to remember all names. Instead, they will instinctively go to the base elements of the human experience: What kind of thing are they looking for? They type “door” and find “wood_door” and “steel_door”, and a whole lot more doors, will appear in their search results. Also the splinters, handle parts, hinges, etc, of all those doors will appear. There is too much stuff! There are so many door assets! In the editor they once saw a rigid heavy iron door. At least that is what it looked like to their eye. They don’t know the name, as they can never remember all names, but they saw it. So they type in "iron door" and suddenly get no results, or the wrong results. Why? Because it’s called “metal_door”.
What really is the difference between iron and metal? We can argue about it all day, including the physical properties, and decide we need to do what the science nomenclature says if we want to be strict. Is that the human experience though? Especially if your team is bilingual and made up of a diverse group of people, it probably isn’t. This is especially the case if you have satellite studios all over the world. The user trying to find what they think is a heavy iron door, while really it’s called a “metal_door” isn’t wrong in their own action. They are not having an unrealistic train of thought. The user isn’t wrong for not finding what they need.
Think of yourself entering your local supermarket. Do you know all the exact names of all the exact items you need whenever you enter the store? Or do you go to the bread section, the cookie section, etc, to get what you need, and then grab what is visually recognizable to you as the item you want?
Now sure, we could make the search even more fuzzy. What if when you type “iron” it also finds things that are “metal”? Okay, but what if you type “metal door”? Does that also make you find the “silver_door” and “gold_door”, considering those are technically metals? Again, as with the naming conventions above, we can spend many hour long meetings and e-mail threads arguing either way. You’ve probably been in a couple of those regarding naming conventions. I’m sorry you had to go through that. Because while it is an interesting thought exercise, it’s also an unresolvable dead end. You may as well argue if blue is the best color. Or the best colour. Here we go again!
Another issue that comes with not being able to remember all names is that your users will instinctively stick to the same assets again and again. Because those are the assets they have used before, and remember the names of. So now you have expensive, valuable, and interesting assets barely ever used, while the same assets are used so often that they eventually lead to the end user of the product being annoyed by seeing so many repetitive assets. When getting feedback from players, viewers, customers, etc, that areas look too similar, you may think “But we have 10000 unique assets, how is that possible?”. Sometimes the answer isn’t in the amount of assets available, but in how easily your developers can use the tools to find unique assets and place them. Having assets is one thing. Having those assets be used is another.
Tags have the same issues as names
Now at this point someone will bring up ‘tags’ as a solution, but they have the same flaws as above regarding multi-national teams, as well as who decides on the conventions. Tags do help! If you have tags, you will be better off for it, but it does not resolve all the above problems in one go.
Furthermore, you will have to keep tags up to date, tag all assets, and make sure tags change if assets change. For example: A door is edited so it no longer has a glass pane in it, because the rendering team said it’s too expensive to place everywhere, but we do want to retain the door asset itself. Who will remember to remove the ‘glass’ tag from that door? It’s a fulltime job to keep that up for 10000 assets. Will you be able to convince management you need to hire a producer or artist whose full time job, or even part time job, it is to consistently check for all tags? Will you ask all your artists and designers to do that next to their regular work? Even if you do, mistakes will be made. It is only human.
Except for one case: AI. If you have an AI that is automated, accurate, fast, and knows the difference in meaning from a user typing ‘iron’ vs ‘metal’, then yes you can use tags. Please let me know if you invent this, and have it work with every editor and engine out there with easy integration methods. The only one I have seen that is getting closer to this, is Promethean AI. They are also trying to have the creation process automated, with editability and regeneration. Please check them out, as I think they’re doing amazing work, and I am very hopeful for the future.
Folder structures and organization have the same issues
What if we organize the folder structure and organization so that folks can easily find assets? This also hits the same issue as with naming conventions: How do you organize them in a way everyone can find them, and everyone agrees with that organization? As with naming something “door_wood” or “wood_door”, you will have to decide on whether the wood assets are in a wood folder, or the door assets are in a door folder. Then later where that ‘door’ folder is located. Is it in a ‘housing’ folder, a ‘furniture’ folder, or somewhere else entirely? You will never get to a location that covers all needs for all cases for all the different projects and people you have.
Even worse: Once you have made this decision, you are stuck with it. If you rename a folder, move a folder, or do anything else to the structure, the entire asset database usually collapses like a house of cards. You may have to rescan for all assets, you may have to reimport all assets, you may lose asset references all over your project, etc. It is a nightmare. And that is without working in the USD file format, where you would have to rename entire trees of references if a single asset is ever renamed.
That doesn’t mean you shouldn’t have a naming convention or folder structure. Of course you should have one. Files need to be saved somewhere, and make sense to the pipeline. But arguing over it for hours on end isn’t going to help. Just pick one that seems ok, and go from there. As we have seen so far, assets shouldn’t be found by name only anyway.
So, what are solutions then? How do we avoid the issue of names for the workflow of an asset browser? There are two good ones I’ll discuss here.
Collections
Unreal has a fantastic feature in their asset browser called ‘Collections’, which alleviates many of these issues by allowing one asset to be in multiple ‘folders’. So there is one asset on your disk or server, but you can have that asset show up in multiple collections. You can have both a ‘Furniture’ folder, with chairs, tables, doors, etc, but also a ‘Doors’ folder that has those same doors in it, and also a ‘Wood’ folder in which all the wood doors, wood chairs, wood tables, etc, appear. A caveat is that this does need to be set up manually by someone in the team, and checked up upon now and then to make sure all the asset allocations inside the collections make sense. It does automatically update over to everyone in the project if you so wish. So it has some of the issues as the above tags, but it does relieve the issue of having to decide on a particular folder or organization structure that then has to be rigidly adhered by at all times, and makes it so that folks do not necessarily have to remember specific names for assets. With collections, you can fill the needs that need to be filled, for the specific project, team, and culture you have.
Much more powerful though is that collections stay with the project, so an art director can decide to use specific assets for a specific area. The director simply drags the assets they want to have used into a collection, and then tells any environment artist or level designer to only use the assets in that collection for that specific area. This allows the team to not only know exactly what assets to use without having to remember names of specific assets, but also lets the team pre-emptively think about the cost of those assets, so the combined instanced assets do not go over a certain memory limit for a specific area, etc.
Here is an example of what a collection looks like:
Which is neat! We can place assets in multiple different collections, organize those collections, have assets appear from child collections but not of parent collections, etc. Collections can be local or networked. It does not resolve all problems with naming, but it does relieve the reliance on them. That’s neat.
What is an other solution?
Zoos & Vignettes
What if you had a single scene, with all the assets inside it? And you can shop around, as if it were a supermarket or IKEA? Just as in a supermarket, you don’t have to know all the brand names of bread, or all the brand names of cookies. You just look around and see what you want. That’s a ‘Zoo’, as I have heard it named before. Though ‘Showroom’ is also a good name for it that wave recently suggested to me. I am open to either name, or a new one. It’s much more important to have one and use it, than what the actual name of it is.
My best guess is that ‘zoo’ probably originates from enemy zoos, where you have a blank level with rooms, and each room has an enemy in it. You can fight it, debug it, check if it works, etc. Or NPCs to talk to, shops to shop in etc. With the same reasoning: You don't have to remember where the enemy, NPC, or shop is located in your possibly gigantic world, or which command and name you have to type into the dev console to spawn that exact enemy or NPC. You just go to the zoo.
It’s hard to understand what an asset zoo is without seeing one, so here is a zoo from Counter-Strike: Global Offensive (CSGO), made by Valve, for a specific nuclear powerplant level they released called de_nuke.
With this zoo we can see all the available assets. We do not have to search for all the roof trims, instead we can look in one place and find them. It does not matter if those assets are called ‘trim_32’ or 'roof_trim_32', or even something like 'roof_trim_small_narrow_32'. We can see exactly what is available, right away, and then click it to find more information if we so like. Or simply copy and paste the ones they need directly over to their level, without ever needing to know the names of the assets.
We can also immediately tell the scale of objects. There is a grid on the floor, and if we’d like we can also spawn a player to see exactly what the relative size is.
Next to that we also see the different levels of detail (LODs) that assets have, right next to each other. What do you want to use? Just take a look. No need to figure out in which folder structure it is saved in, or what its name is. Just take a look around.
The same goes for materials and textures. What was that one material or texture called? It doesn’t matter: Just go take a look. You can even run the map in-engine with final lighting to get a greater idea of what that material looks like in specific lighting. Or even what an asset with that texture on it looks like! If the assets have animations, you can then also see those animations right there in the zoo, possibly even have a trigger for them so if the camera gets close, the animation automatically plays.
In an asset browser, the features of a ‘scale check’ and a ‘lighting check’ are often missing. Both are significant, because not having a scale check often makes users drag assets into their level without knowing it is way too big, or way too small. And a missing lighting check means the user has no idea if this asset looks good in their level until they drag it in, and recompile lighting or wait for enough bounces. Dragging in an asset can take a second, or multiple seconds depending on the speed of your editor. Users do these actions all the time, especially in the case of environment art and level design, so these times of waiting add up. You could of course add those scale and lighting check features to an asset browser, or make a zoo that accomplishes these goals and more.
We do see the frames per second (FPS) dropping now and then. Performance can be sluggish if you have all your assets in one place, so adjusting the clipping plane or hiding/unhiding sections of assets can be useful here. In this case it’s all the assets for a specific level, and not for the entire game. I have seen zoos before that cover all assets of an entire game, and depending on the editor and engine this can run fine. Your specific performance may vary depending on your use case, but various adjustments can help alleviate those framerate issues while still allowing your users to fly around and take a look.
Let’s take a look at an other example, from de_ancient, another level from CSGO, set in an ancient temple.
We see a lot of the same setup, with different assets, again giving us an extremely clear idea about what assets are available, what size they are, what they look like, etc. No need to go one-by-one in some internal asset browser 3D view. Instead we look at it right there in the larger 3D view the users are used to. Let’s take a look at that last part though, where we see a few assets being used together to create a vignette:
This gives the users a really great idea of how to use the assets in a way that makes sense. I call these ‘vignettes’, as they are a small setup showing intention, but not a fully built level. They are not created to be copied over and used as-is, but merely show how assets can be used. The user can then decide to follow this example, or try out completely new things. Art directors can then also set these vignettes up so that artists and designers have an idea of what is intended to be evoked, and in what way. Artists themselves can also experiment, and leave them in the zoo, so that other artists can see what interesting setups there are. You can add lights, audio, VFX, etc, to these vignettes to create even better examples. It creates a space of inspiration, where you can simply look around to find out what you can build. Instead of rigidly remembering the assets you have used before, you can get ideas in the blink of an eye.
These zoos can be made manually of course, or you can automate them. Software will have an easier time running through all folders, assets, etc, without accidentally forgetting a specific name, modifier, etc. If your project, engine, and editor allows for a way to automate the creation of zoos, then the concept of a zoo can function as if you are smoke testing and unit testing for art, design, VFX, etc. Set up a lighting zoo, set up lighting vignettes. Place all the VFX in one level and organize them for easy debugging, easy reference, testing, etc. Then have someone fly through a specific zoo once a week, or even with an automated camera on a spline, so that they are automatically taken past everything in the zoo, just taking a look for 10 minutes, and you will save a lot of time. It enables you to quickly find issues with assets such as wrong scales, flipped Y and Z axes, materials that broke, etc. Those are often much harder to find in the incredible dense levels and maps of your project, and usually result in a steady stream of Jira tickets. It’s nice to cut that off at the source, with a single source of truth: The zoo.
You may still end up with the question on whether a door asset is in the furniture section or in the housing section, but when you combine the ideas of collections and zoos, you can have one asset in multiple places inside that zoo.
Another game that has done this is Overwatch, where they showed off an asset zoo very quickly in a developer video, around 2:33 in:
Another great way I have seen this done are the content examples from Unreal. They use a gallery/museum style of functionality, assets, techniques, etc, with a description of how things work and why.
Is that exactly an asset zoo? No, but you get the idea of how a setting up a zoo/museum/showroom can feature content, features, and assets in a way that make sense and requires much less know-how and tribal knowledge of names. And the size of their chaos destruction level is huge:
It runs really smoothly as well. Flying through it, taking a look around, feels very simple and nice. There are many more examples out there, for example of the TF2 level design community releasing their Swamp art theme pack with a zoo and vignettes included (shoutout to TF2maps.net), but let’s get to a conclusion.
Pick a naming scheme, and stick to it
You should have names for all your assets. These names should not be a garbled mess. But you should not have many hour long meetings about them, and you should just pick something that fits the pipeline. The key here is not to get stuck in finding the perfect naming scheme, as you should not be using names as the primary way of finding them anyway. Instead, locate the original source of the issue that makes pipelines rely on names in a bad way: The human beings searching for assets.
How do we resolve the issues for human beings as best as possible, and not get stuck with hour long meetings, decisions, and an ever unresolved problem? With, for example, collections and zoos. Making the way to search for assets more human.
What about other asset browser features?
Sure, there are a lot of other features we can think about for asset browsers. What could an asset browser have? Some kind of tiled structured view, but also a view that’s row by row as a list? What about a detailed view that also shows triangles, data size, etc? Can you export that filtered asset list to a CSV? It probably also needs thumbnails, but how are those thumbnails generated? On import? How are the assets lit in those thumbnails, and what light source do we use in them? Can you click and drag those thumbnails so they become a 3D view, like you can in Unreal? Can you then save those new views as the thumb for the asset? How does the search system work, and are there tags? How do you remove and add tags? How do you remove and add tags in bulk? Can you rename the assets? Can you bulk rename assets? What about reimporting or bulk reimporting? Is there a bigger thumb or 3D view that appears when you select the asset? What happens if you select multiple assets? What if you double click an asset, or multiple selected assets? What do we display for audio? Do textures or materials get shown on a 3D ball or as a 2D plane? Do animations and VFX play in the thumbs, or do we grab a single frame? If so, what frame do we grab for the thumb? Are there play/pause controls? Etc, etc, etc.
All great ideas and neat features, if you need them for your workflows, but if the core concept of finding assets doesn’t work, especially because of a deep focus on searching by name, then you still have an asset browser that does not cover its main function.
Thank you for reading! If you enjoyed this post, you can find my talks here, and my other posts here. You can also subscribe below to get a notification when I release a new post.