We(the SC) have been talking on porting over T2D's TAML, Asset and Module systems into T3D at some point in the future, and I began looking into how that would happen.
Thanks to Lukas' prior work in getting TAML ported to my Entity/Component branch, it didn't take me long to get TAML working on the latest and so I've started meandering my way through the asset and module parts to get an idea of them.
Az insisted I throw down something on the forums about it to get people talking, feedback and for general "this is a thing happening", so here we goooo.
One thing with Torque is that while the art pipeline isn't BAD, it is however unrefined. It's pretty flexible in what it allows you to shove into it and largely doesn't break anything when you do, but updating assets, moving things around, and inter-dependencies between stuff like models, textures and materials can make managing them a mess.
So, today I was brainstorming on it, and came to the idea of implementing asset files. Torque already does this in a fashion with models. You hand it a collada dae, and it processes it and spits out a dts that the engine actually uses. After that point, you can stop using the source collada file and use just the cached edition.
My thoughts on that are to expand that process to cover any and all content assets the engine would use, combined with the asset system in T2D to assist in the management and tracking of them.
And so, you would have a torque asset file. *.tasset, if I wanted to totally ape unreal's naming methodology, haha.
The idea would be that you'd import a peice of content via the editor - sound, texture, material/shader, model, animation - and it would process it and save it out as a *.tasset file(or whatever we end up calling it. For now I'll stick with tasset)
The tasset file would contain the peice of content, as well as a header that is a taml asset descriptor. So it'd provide version data, dependencies and other easy-to-read data in addition to the binary data of the content itself.
This allows several things at once. One, because all assets would exist in this fashion and be handled via the asset manager, WHERE the assets are located is irrelevent. Each asset has information about what other assets it's dependent on. So you have a model that requires TextureA, TextureB and TextureC. They don't have to be in the same folder at all. They just need to exist in the game directory.
In the same vein, it makes the loading code much easier. We can have just one pass that loads all the tasset files in a directory, and because each tasset file can describe what it is via it's header, we can know what to do with it incredibly easily inside the engine. Script-side would be one standard function to load a tasset file and thus could automate the process by a large margin.
In additon to that, versioning/updating assets would be easier. Because we can store version data in the header, it's very easy to pull and compare to see if files are out of date and the like. We can also easily to categorization tags, so it's easier to sort and group assets.
So how would we actually use and make tasset files? Well, we'd need a content browser. Good news though, we basically already have that in the Material Browser.
You'd just expand the same browser UI to work on all tassets. The process from a user-end of things would be to open the content browser, and click a button to import a new asset(or drag-n-drop an asset from your computer to the editor window, which is easy to implement, I've already done it on my internal build) and it'll read it in.
You'd save the tasset file to whatever directory you'd be inclined to as well as put in additional information if needbe, such as version number, categorization tags, etc.
At that point, the tasset would exist in system, and thus would show in the content browser - categorized based on type and/or tags.
If you already have a tasset file and just want to copy it into your project, you'd just open it or drag-n-drop and poof, you're good.
This also removes the need for source files to clutter up your game's directory if you're so inclined and export functions would be as easy as 'save the binary data to a new file at location X' through the content browser.
One other fairly big advantage this would provide us is standardizing the internals. Take textures for example. Torque supports quite a few different types. If we go the tassets route, we could decide on an internal-format of it(because the binaries would save into the tasset file itself anyways) such as DDS. We could do some nice automagical things, warning the user if it's non-pow2, generating mip-maps for them if they want, testing if it's a linear texture, etc. This lets the engine know definitively what sort of texture it's got on hand and can make some things a lot simpler to deal with.
So yeah, figured I'd write town the brainstorm, and see what people thought of it. I think it'd make a LOT of things easier when it comes to using torque in regards to the pipeline stuff, so I'm curious if other peeps feel the same.