Nachiket Kumar: since my original comment regarding libraries was before understanding your plans for local folder watching via the desktop app, the above makes sense.

Our use case for Libraries would be to gather similar assets together that might be stored separately in our file system, ie, all Weapon Models, all Character assets, all props for a given location/map, etc.

Our file system, on the other hand would be orgaized in a more complex way, such as having individual folders for each weapon asset and then separate folders for working files and another folder for asset exports.

Libraries in this instance would be used to quickly see all assets in a group. And sub libraries would be just to keep things a bit more ofganized, ie having a Weapon Library and then sub-libraries for different weapon types.

However, when downloading assets, it's important that the export follows the File system hiarchy. Or there is an option to export directly to the Unity Assets folder / Unreal Assets with a defined hiarchy that can maybe be customized on export

JustinFrench: Right— if you set up your cloud directory structure the way you need it to be for Unity/Unreal, then when you sync it to your machine, it will keep that hierarchy.

This would be regardless of whether you synced a folder/file or library— the underlying cloud directory structure would be respected and synced locally.

Nachiket Kumar: That's essentially what they're for -- organizational purposes. Some of the use cases where folders make sense: 1) make-shift workflows (i.e. folders Unsorted, Approved, Needs Work, etc.) where assets move across the folders as they are processed. 2) Organizing/sorting (i.e. dagger-icons-epic, dagger-icons-common) and so on.

Some of these things could potentially be accomplished with tags, but you lose the ability to visually confirm everything has been sorted without having to click/filter/search on tags, etc.

I am curious about the folders not showing up in the local filesystem -- seems like it would be easier to allow the local filesystem to reflect the folder system rather than the opposite. The ability to "zip" assets into the desired hierarchy seems like a good idea, too. I think the idea was to allow users to selectively download assets and group them by tags/folders or something -- that's a good idea. Whether or not the local filesystem reflects the folder structure or not is irrelevant if the download functionality is present.

jpreed00: To be clear around the 'folders not showing up in the local filesystem' -> I'm referring specifically to folders inside of libraries.

Because files can be in multiple libraries— these library subfolders are not actual "folders" represented on any filesystem— they are more akin to tags but visually distinct for the use cases you mentioned.

We will be introducing folders in the cloud, so your workspace will have a folder structure that you define.

When you sync any of these workspace folders locally, those folders show up on your local filesystem (likely in a mudstack folder that contains root folders for each of your workspaces).

Does that make sense?

Nachiket Kumar: Ahh, yes, that makes sense. Thanks for the clarification.

Nachiket Kumar: ill have to sit down and discuss this with the team in a bit more detail, but generally our working file directory and asset exports are kept separate to our Unity/Unreal asset directory as we generally want to avoid having working files being sync'd to the Project asset folders. Only final, approved files should go into the Project folders.

The Libraries could, essentially follow our folder structure in the Project Asset folder though on export.

JustinFrench: No worries. In that case you would set up your cloud directory however you want — that would be your working file directory structure.

Down the road we will address this via integrations into your Unity/Unreal projects.

Right now the goal is to minimize changes to your existing workflows (unless those are broken and problematic, in which case the change is welcome!).

Let's keep the conversation going as we move along in the beta and start to incorporate local files in the next phase.

JustinFrench: Thanks for sharing. Would you want to see the full library structure at the top level (i.e. show me all the libraries when I am in the libraries section, along with a hierarchy— which libraries are top level and which are nested)?

Also, how many levels deep would make sense?

Nachiket Kumar: At the top level, all libraries should be shown, but perhaps with a labelled separator that splits the library by its folder structure. Something like the attached wireframe.

Clicking into the folder structure on the left would only show the selected library and child libraries within the structure.

JustinFrench: Thanks, so in this scenario, would Launch Trailer itself only be a container for sub-libraries or also contain assets directly within it?

Nachiket Kumar: It would just be a container for sub-libraries in this case.

However, that's not to say you couldn't have it so it could contain both Assets and Sub-Libraries as long as there is a visual differentiation between the two; perhaps using icons (a little library icon in the top right of the box? - could have other icons to denote asset types too), border colour or something similar to denote types.

But for the time being, having it so you can create Libraries or Library Containers would be enough to allow for some organization on a high level.

JustinFrench: Yeah the UX is something we can figure out. I just want to understand the use case first :)

Nachiket Kumar: The use case is just general organizational structure - I have a feeling as we start to add assets to MudStack, things are going to get very very messy without the ability to have some kind of folder structure to properly organize things.

Tags are great for quickly finding assets of a given type, but less helpful for organizing groups of assets tied to maybe a given game location, marketing campaign, DLC, etc.

JustinFrench: yup— totally see that. Let's discuss in more detail during our call— the Desktop app should solve a lot of these issues (because there will be folders) but sub libraries might still need to be a thing.

Nachiket Kumar: I think tags can handle some of the desired functionality here. Nesting Libraries is definitely something we can think about, but I almost wonder if instead we look into supporting a hierarchical view of search results. Each asset could have a path similar to being inside a file system, and we would have the ability to swap between grid view and hierarchical view. I've been thinking about that for a long while, as I think it could work well with onboarding from file systems. We should discuss at some point in the near future.

Jordan Stevens: So I may have a more niche usage, but one limit I see with tags is when it comes time for me to pull the assets. Now if I could pull/download my entire library in a .zip and it could then package the files into folders named after each tag that would be awesome. Cause right now, if I get everything perfectly tagged and sorted, it all goes away when I pull the assets.

Luke: Interesting. How would you want assets w/multiple tags handled?

Nachiket Kumar: I would be fine personally with having it duplicated. My personal example is wanting certain game assets with a "Marketing" tag folder also in a "Textures" tag folder.

Luke: That definitely makes sense. I think that could definitely be an option for bulk download. Some sort of Group By control that allows you to pick properties to group the assets by in the zip.

i.e

Group By: Tags

or

Group By: AssetType

or

Group By: Library (if downloading from "Workspace Search" instead of "Library Search")

Taking that a step further, you could even group by all of those in a specified order.

Something like Libraries -> Asset Types -> Tags

This does sound like a very valid use case, so I think we definitely need to think on it.

Nachiket Kumar Great line of questioning there. Duplicating assets in the multiple tag scenario is an option.

I don't see a super quick rough answer. We will have to think critically here.

Jordan Stevens: That all sounds fantastic. Something like that would make my life and workflow so much easier.

Luke: It almost reminds me of the old unitypackage workflow from Unity 4. Whenever you wanted to share assets between projects you would build a unitypackage that was effectively a glorified zip that also contained prefabs and stuff.

Will look at that stuff for further inspiration.