Working on a Digital Asset Manager built using the Godot Engine. I've yet to find a tool that matches my specific requirements, so I'm building it myself!
The main purpose is to easily and efficiently browse my asset catalogue.
There is easy support for gltf, ogg, png, and jpg. Will try to support everything else though (mp4, flac, bmp, fbx, whatever).
@SirLich I got REALLY close to start writing one of those myself recently, though I think I would've gone Qt instead. I myself have collected a lot of asset packs over the years and browsing them all looking for stuff can be quite the pain
@VileLasagna So my reasoning for using Godot is that I mostly want to use the assets in godot. There is still some friction (namely, some stuff is stripped from exports, like fbx to gltf), but overall supporting the basic types is a breeze.
@SirLich For me I think I was thinking of this before I got deeper into Godot as a more general solution... Was actually thinking now if I wouldn't want to go that way instead if I were to start it today. One thing that DOES give me pause is that file system support in general is way more solid on the Qt side, AFAIK, so that could make all the probing and indexing and whatnot easier
The immediacy of Godot being the target itself as well IS really valuable tho, I agree
@VileLasagna I ported the relevant parts of Pythons PathLib to GDScript, so dealing with the path stuff isn't too bad. I wish windows had native support for file tags, because building a tagging system is going to stink...
@SirLich I don't think any file system has that natively, does it? It always need to be some metadata present in the file itself (like sound and image file tags). You'll end up having to either spin up a portable DB or building an index that you write as a hidden file in each folder (pollutes a bit but would make it portable)
@VileLasagna Well as far as I'm aware NTFS has somewhat stable file IDs, but doesn't otherwise have any space sketched out for arbitrary metadata. I would personally be very happy to pay for slightly larger minimum file sizes in order to get native tagging.
@SirLich Same here, but I think there's some tricky things to consider once you start thinking about moving files around. If you move your file to a different file system, what happens to those tags, etc...
I think that's part of why sort of thing never ended up baked in the FS themselves. I think keeping a separate index is pretty much unavoidable, especially if you want your solution to be cross-platform
@VileLasagna Separate index requires some kind of always-online daemon to listen to WINAPI FS events and update things as files move. Hence why I said rolling my own tagging system is going to be a pain 😅
I will probably tackle that last, after I get good search and navigation working, as well as all the preview options I want.
@SirLich Can always just do a scan on load and explicitly not support changes made externally
This IS also mitigated if you write everything to a .asset-tags file in every folder, which is the slightly polluting solution I was talking about. This way your program can look for the tags there when it scans the folder. Even if you move it, those would get moved with the assets
Add comment