Repository navigation
Replies: 1 comment 1 reply
📦 New project layout: Resources vs. GameData — now testableWe've reworked how projects are organized and how the Asset Browser handles imports. Here's what's changing and how to try it. The big ideaProjects now have two clearly separated folders at the root:
Previously these lived mixed together. Now the split is explicit, both on disk and in the editor. How the new workflow feels
If you already have a cooked file (say, a The first time you import a single file, you'll see a one-time reminder that it landed in Resources and how to cook it, with a "don't show again" option. Asset Browser sidebar changesThe sidebar now groups things under two destinations — Resources and a collapsible GameData (holding the same categories as before: Models, Animations, Scripts, etc.). Empty folders show a short hint about what belongs there instead of a blank panel, and a breadcrumb above the file list tells you which tree you're browsing, since Resources and GameData can have same-named folders. Converting an existing projectIf you have a project from before this change, convert it in place from the terminal: This restructures it into the new layout without touching your assets. You don't have to convert immediately — older projects keep working as-is, they just won't have a Want to try it now?This is still in testing before merging to
Feedback welcome — especially anything that feels confusing about where things land or how to organize |
Uh oh!
There was an error while loading. Please reload this page.
I would like to propose a new folder structure for the projects the editor (and
untoldengine create) generate. The short version: today a project mixes the artist's sources, the engine's assets and generated files in one tree, three levels inside the code, surrounds them with empty folders, and ships files in the app that the engine never reads. I propose four folders at the root, each with one owner.GameDatakeeps its name and its content and moves to the root; the runtime does not change.Why
This is what a project looks like today, as the BuildSystem creates it and the editor completes it on open:
What I run into with it, measured on my own project (one model pack of 375 models, visionOS):
GameData, ten of them empty. An artist or a designer opening the project has no idea where their files belong, and the one folder that matters is three levels deep inside the code tree..blend, the editor copies it intoGameData/Models/<Name>/and the cook writes the.untoldpackbeside it. The.blendis 96 MB. Sinceproject.ymlbundles the wholeGameDatafolder, that.blendships inside the app, together with every other working file I drop there. The browser hides the source folder now ([Patch] Hide cook-source folders in asset browser #154), but the files are still bundled.GameData(and get bundled) or outside the repository..gitignoreis written, so the Xcode project,.build/,DerivedData/and the bundled copies all look like they belong in version control. The generated README documentsmain.swift,GameRuntime.swiftand.jsonscenes, which the template does not produce.LUT). The chainSources/<Name>/GameDatais repeated in both repos, and the project root is found by walking three levels up from it.Proposal
Resources/GameData/Docs/Sources/Compiled output stays where Xcode and SwiftPM put it. There is no build folder in the project.
My project after the change: the
.blendinResources/Models/EDIFICIO_COMPLETO_BLOCKING/, tracked and never bundled; the pack and its payload folder inGameData/Models/;GameData/Scenes/once a scene is saved; no other category folder on disk. The app bundle is the same as today, minus the.blend.What stays the same
project.ymlbundlesGameDataas a folder reference and the app looks it up by name, exactly as today.assetBasePathpoints at the same folder in the editor, scene references stay relative to it, the category names are the same. Every doc page that saysGameDatastays true; only the path prefix changes..untoldpackconvention and the browser rule from [Patch] Hide cook-source folders in asset browser #154 are untouched.Resources/), and the pack manifest already carries asourceAssetfield, today a bare file name that nothing reads. Written as a path relative to the pack, it points at the source wherever it is.Resources/would show in the browser as a second root, so cooking from a source stays one click.GameDatais still underSources/<Name>/is treated as the current layout and works as it does now. Moving to the new one would be an explicit command (Convert Project Layout…in the editor,untoldengine converton the CLI) that moves the folder and the sources, rewritesproject.ymland the pack manifests, writes the.gitignoreand logs every move.What would change
GameDatafrom the root), aProjectLayouttype that both repos use instead of the five lists,.gitignoreand a correct README at creation,updateandassets installfinding the rootGameData, theconvertcommand, the path prefixes in the docs. The SwiftPM variant needs its target at the project root so it can bundleGameDatafrom there (to verify), otherwise it would go, since only macOS ever had it.ProjectLayout, imports of sources intoResources/, cooks intoGameData/, re-cook throughsourceAsset, the convert command, and the script package the editor generates for USC scripts moved out of the asset tree (today it is bundled with its own.build/).sourceAssetas a relative path (one line; the reader accepts both forms).Three PRs, engine first since the editor pins the engine's develop. I estimate three to four days in all.
Open points
.xcodeprojignored (it is regenerated byxcodegenand by the editor on open; the engine's own sample project ships without one) or tracked.Shaders/folder at all; my project runs with that folder empty, since the runtime falls back to the engine's own bundle.untoldengine updatekeeps a role for new projects (pulling assets from an external folder intoGameData) or serves existing ones only.If this direction makes sense, I would prepare the engine PR first (templates, layout type, docs), then the editor one.
All reactions