s&box
02 October 2017

Dev Blog 4 - Assets

Our plans with Textures, Materials, Sounds, Maps
Garry Newman
Programmer
United Kingdom
The Old Way
In the old days an engine would define its own format. It'd make a bunch of tools to work with that format and that's what you'd use. There's a lot of good reasons why this makes sense. Storing the file in a raw format that's fast to load because it's already appropriate to load straight up (like DXT compressed textures). This is friendly to the engine, unfriendly to the developer. I used the Source engine for 10+ years and the complexity of doing something pedestrian like importing a model still haunts me. Even really basic tasks like converting a texture into a VTF required command line/bat file bullshit until third party tools started appearing.
The New Way
Modern engines like Unity and Unreal take the sting out of this by converting for you invisibly. This is a lot friendlier. So if you want to import a fbx model, you use the fbx file. To your small brain it feels like you're using the fbx file, but internally it's converted that fbx file into the internal format that it can use. UE and Unity can get away with this workflow because they cook all of the content at the end. Your fbx file and your TGA textures aren't even shipped when you build the game. They're converted into an engine friendly format.
Our Way
Our way attempts to walk between these two lines. We envisage it working in two ways. When you're making a mod you have your files in a raw format. You have your addon folder, all the files inside are standard everyday formats.. fbx, tga, png, jpg. There's an obvious disadvantage in these being slower to load than the engine friendly format. So when we load then we create a engine friendly format and cache. So next time you go to load the asset and it hasn't changed, we'll load the cached engine friendly format. When you create an addon and upload it to workshop (or whatever), we'll output the engine friendly files and leave out the easy access files. This means that people won't be able to download your addon and get a plain view at the contents. You'd be expected to also host your addon somewhere else (like github), as the source code version (rather than downloading and editing your workshop version).
Importers
You can write your own importers. We're trying to keep our default importers as addons, so anyone can read and learn from our code. Here's our default texture importer.

This is made very simple by the fact that we have an image class that can load image files, and we're not dealing with texture compression yet, but you get the idea. One of the things that is quite interesting about making importers creatable is that it generates a lot of interoperability. Within a few days we can make the engine read another engine's formats.
And now we can load Source Engine BSPs. There's obviously a lot more to it than that (BSP is a real shitbag of a file format). And then you have to solve a bunch of other stuff - like loading textures and sounds. To be clear here, our intention isn't to make a version of the source engine and use all the same tools. But since the Source engine has an abundance of assets, we're using them to test. We have fbx importers too. You've probably seen before but we can drop assets from Rust in with minimum effort.
The Dream
We've got a bit of a dream when it comes to assets. It's a big stupid dream, but it's something we want to try to make. Our dream is that you'll invite your friends to your server and you'll create together. In a multiplayer environment you'll all work together to create something. A map, or a model, something. That's nothing really new. People do that already in Garry's Mod, Rust, Minecraft. We want to be able to create something useful. So you'll be able to create a map and export it and use it for some other purpose.. like in a gamemode, or in your own game, or an achvis of your house.