Hey guys! Updates, woo!
Unsurprisingly, a fair bit of work has been happening. Beyond the regular spread of bugfixes and improvements in PRs and the like, we've got a good bit of work continuing on the forward-looking stuff.
We've think we've got the PBR math pretty well dialed in, it's just a matter of getting it rolled together from different WIP builds so we can finalize things before finally merging that sucker into stock, so that's very exciting.
On my R&D side of things, I've got a fair number of bits I've worked on since the last update. I've been further improving/refining the new assets/importing stuff. There are now asset types for levels, post effects and scripts. I've also implemented an addition to the module definitions to auto-load certain asset types when the module is initialized.
Normally, an asset is only actually initialized/loaded when it's referenced - for example, an object that renders a shape references a shape asset, and this informs the asset it's referenced and if it's the first time, runs the init/loading stuffs.
This is largely fine, but there's some cases where we need stuff loaded up-front. Stuff like scripts, levels, post effects and a few other special-cases where we want that kind of thing in effect all the time as opposed to only when a mission is actually loaded. This conveniently happens to also remove a lot of the extra script fluff for setting stuff up, such as removing the need for a lot of the exec files that only existed to exec script files, etc.
The level asset is nice because it means that as long as it exists as a valid asset for a module, the level selection screen can automagically detect it, regardless of what module it's in. This gives a lot of flexibility in how to handle modules and packages, and will make doing stuff like demo scenes a lot easier since it means everything can stay self-contained in it's module if you want.
I also started - piggybacking on the asset importing work - initial work into a refactor of the TSShape stuff. While it most certainly works still, I don't know if you've looked at it, but it's a pretty spaghetti-tastic mess of code. Rendering any given shape out of one of the game classes sees at least 7 function calls to make it happen, which is pretty rediculous. I have basic mesh rendering working, and the plan by the end is to replace the TSShape stuff, with all functionality intact(and room to expand new features) while being appreciably cleaner.
I also started work on a Tileset Object Editor tool. This utilizes a bit of a rework of how new tools are done in the engine. The current way, you basically have to write an entire gui control that replicates the general functionality of the world editor, but then also does it's own special stuff. It leads to a lot of unneeded complexity and duplication. Then on the script side you end out doing a lot of swapping back and forth of GUI controls and we've seen it break before with some swaps not happening so editors get 'stuck' and the like.
With this, you enable a much smaller class object derived from the 'EditorTool' class. When enabled, it pretty much just intercepts the inputs from the regular World Editor gui control, and piggybacks off it's rendering. This keeps the tool's code streamlined and to-purpose, and simplifies the script side as well without losing any functionality.
So, the Tileset Object Editor is something i'm doing up for my project, which uses a lot of factory/industrial space stuff, so I made the logical conclusion to use tile meshes. But rather than having to do a ton of work placing and gridsnapping everything manually, I figured I'd draft up a relatively simple tool to streamline that.
Here's what it currently looks like:
From here, the plan is to get tile sets working. Think like how you can have your Forest Items in the forest tool, and then can make brushes of multiple items you can rapidly paint down. My idea is you could paint down say, several unique floor tiles, or wall tiles, select the set, and save that set. Then you could either place them down like a stamp, where it'll fill in as per the tileset's arrangement, a random selection from the tileset(which would help break stuff up to avoid obvious repetition) or a 'fill' paint.
It's pretty project agnostic, ultimately, as long as you use tile meshes to build your stuff. So that should end up being pretty useful
Speaking of editor stuff, I also did some modifications to the VariableInspector gui object. I'll have to specifically demo that off, but the idea is it'll let you do arbitrary inspectors. The current Inspector Control used in the editor lets you select an object, and it'll populate with the fields that object has exposed for editing purposes. Awesome and effect, but limited.
This lets you add fields yourself via script, can be pointed to an object's fields to be updated, or can point to global variables. It'll try and find matching engine-defined types, but it also lets you implement completely custom field types(if you remember the fancy-looking Material Slot field on the MeshComponent that had the preview image and stuff, it lets you do things like that.
You've actually seen this in effect without realizing it in my asset import videos, where you can see the Asset Import Config editor control having that nice list of options to edit.
That'll be getting PR'd soon, and with that, it'll let us update a lot of special-snowflake GUI controls to have a simple standard layout that's just as powerful but far, far easier to work with. The first things on the chopping block for that to try is the madness that is the material editor's GUI, and editor settings.
Anywho, I think that's everything for the moment. If I missed anything I'll be sure to update this