Mainly because of file versioning / backup reasons.
Example of the current situation:
You edit a sound file in Audacity. Source file: 30 MB. Exported wav: 15MB. Imported uasset: 15Mb.
Why isn’t a UAsset just a JSON file containing any import settings you alter in the editor + a path to a source file, excluding the actual asset data? There’s no need to make a full copy until you actually want to read that data like when previewing a sound or playing the game. It could technically be “built” into a cache directory excluded from a git repo? Yes… it’s awkward to use a Git repo for binary files but it is what it is. If it were up to me blueprints would also be text based already and not store their entire node and pin graph in there * shivers * any plans?
But then it would be time to change the way the whole content browser works.
I think it might be a good idea, because then you can have a ‘one copy’ asset library, but it’s so far over the horizon, I can’t even see it with my telescope…
The launch of UE5 would have been a perfect time to overhaul and fix the old stuff. One can dream.
Single use browser would be a great thing. I’d use about half the current space
It’s on my mind to make this myself, just need to check what the content browser supports. Unless I’m missing something else this feature doesn’t actually seem a big request for most data types. The importers exist already.
Definitions:
-
UAsset: (idea) Becomes a cached file in the new BuiltContent folder, read only. Folder excluded from Git. Binary.
-
SC: SoureContent file, data made from within the editor (datatable etc.) to build into UAsset when saved. Text based. Only exists for files made within the editor.
-
SCI: SourceContentImport file, used to build source as UAsset. Text based.
The SCI contains:
- A path to SourceContent.
- Any property + value if different from defaults.
- Importer instructions if different from defaults.
Concept
As a plugin perhaps an engine subsystem could listen to when an asset is requested or when one is failed to be retrieved. An asset should be looked up in this order: UAsset in BuiltContent, SC in Content, SCI in content. If the SCI step is reached and source file is found it will initiate the import process. After the import process all you need is a retry on finding the asset once more as UAsset. SC is not created by the importer.
Challenges
-
Use the original UAsset editor as a front to create text based SC assets with. This is preferred as shown property names often differ from c++ names and without access to UAsset files we would otherwise not be aware of any properties.
-
Assets which are too deeply tangled with the engine can be excluded for now by data types. Think of animation assets with hundreds of fragile event / skeleton / sound references. Sound files, textures, meshes etc should be very much doable.
-
Some work might need to be done on the redirector system and asset renaming system so we can rename the entire set of UAsset SC and SCI from one place.
-
Changes made to a UAsset by the engine must be reflected back to the SC file. This can easily be done, there are delegates for this.
-
If all works well and there is found no further reason to have a UAsset, deprecate the UAsset extension.
Something else but wrapping excel sheets in a binary file (UDataTable) is just too cursed. I’m a big fan of having my data to set up objects in text sheets, it’s just so easy to modify and calculate proper numbers. Especially if you need to rebalance things like EXP over 500 character levels or item spawn chances per faction and similar stuff. At least I would want to be able to diff that in 2024.
You’ve got your work cut out there, I think
Took my time to sketch it out, might get more people interested in the idea. I have quite a todo list right now but before I start making non code assets for my game project I am going to test this out. Should take a few days, maybe a week to get something running. As long as it does not require engine modding I try to stay away from that.