It's that time again!
So the bugfix slap-around that is the 4.0 Preview build continues to pay dividends as issues are identified and pretty quickly corrected for, which is excellent.
So what's been worked on this last month?
So, going through the commits log, we've got roughly 60 different commits or changes since the last workblog. Some of which are, predictably bigger than others. A big recent one was Blood and Timmy getting assimp updated, which is awesome, and I've been taking a lot of feedback on the asset browser to fix things as well as adjust how it all behaves.
The rest of November will pretty much be dedicated to catching up the lagging parts of the asset integration/pipeline and dialing it in based on feedback.
PBR is pretty much done as well. I think we had a few oddities or nitpicks come up that'll get a little attention, but at this point practically everything we throw at it either behaves as we expect, or if it does break, seems to break in the same way every other engine does, so I'd say that's probably a pretty solid level of 'acceptable' for a first pass.
Leaning to that, Blood's been utilizing the asset pipeline more to help me hammer it out, and also get used to it and the PBR stuff, and he managed to start getting some rather fine looking art loaded on in:
For the asset browser work itself, it's gotten some fair bit of attention as well:
As you can see, there's a little bit more going on with it.
For highlights: There's now a navigation system, complete the with breadcrumb chain you see at the top. The arrows will step backward/forward through the navigation history respectively, which is useful for quickly bouncing around a project's content, and it's now folder-driven rather than being just forced to adhere to asset-type groupings. This should allow a lot more flexibility when organizing project content without impacting how assets themselves behave(as they still operate on the <moduleName>:<assetName> id reference system rather than direct paths.
Searching has been updated, allowing both searching of the folder hierarchy and assets in the current selected path, and I'm working on expanded filtering options so you can easily filter by asset type when just browsing, so if you're only looking for a shapeAsset, you don't need to worry about anything else.
Asset importing, likewise, is driven by the path setup now, so it'll import any new assets into the currently selected path.
I've also added more asset import functionality, including the ability to set a default asset import configuration, and the ability to auto-process the import if there are no errors, so you don't even need to bother with the confirmation window if everything is error-free and you have your config set up just the way you like it, which should streamline workflows appreciably. If any errors ARE detected, then the asset import window will open so you can correct the issues and continue.
I also added the ability for it to auto-generate PBR Composite/Config maps from any detected metalness/AO/roughness maps, soas to save on rendering overhead by binding fewer resources. This way, art packs or tools that output the separated masks can just be imported in and let the importer do the work if you have that set as active.
For the editor itself, ongoing catchup of missed bits for the theme is progressing, and there's almost nothing at this point that isn't fully converted to the adjustable theme system. Helps everything look clean and consistent, which is great
Also per feedback, some new editor settings:
First, an adjustment to how the editor is opened from the menu:
Here's the setting that control the behavior:
At the top, you can see the 'Startup Mode' setting. This has 2 options: Blank Level or Last Open Level.
Instead of doing the weird route-through we do currently when trying to open the editor, which requires piggybacking off the ChooseLevelDlg from the UI module, we use these settings.
The main reason for the change was the realization it's actually really easy to break that behavior if you have a UI that, well, doesn't operate the same way that the stock UI modules does and doesn't have that ChooseLevelDlg to piggyback on, then everything will just go asplodies.
So, instead, the new setting dictates how the editor opens.
Blank Level will just make it load into the default blank level, as one would expect by the name
Last Open Level will load the last level that was edited which is good if you're working on a particular map consistently(great for level designers
In addition to those, a new addition to the File menubar item:
It'll track the last 10 levels that you'd been editing, as a quick way to crack open something you'd worked on prior(like just about every other tool in existence now)
As an aside, you also may have noted another setting in the Editor Settings above: the "Force Sidebar Window(s) to side". One complaint that comes up a fair bit is the annoyance that the Scene Tree and Inspector windows are floating, so if you resize the window, they don't always correctly stick to the side as one would expect. As the modern, panel-driven layout isn't ready for prime-time yet, I went ahead and added that setting, which will, as the creative name would imply, force those windows to adhere to the side. They can still be moved, but will be re-positioned whenever the game window is resized.
Block Out Party, baby!
One thing that came up was a lack of good placeholder/blockout meshes. I'd actually started a small foray into that a few months back but didn't really have a good idea of what I wanted out of it. The topic recent came back up, with suncaller bringing the idea back, and so I started a more robust plot-out of the notion.
Thus, the concept of the 'BlockOut' assets was born. I plan to have a number of small, concise, but flexible packs that are designed to let you block out(duh) your levels with a lot of common bits that can then be very rapidly replaced with final content once the level's design has been locked in.
I took some notes from the old 'Orange mapping' a la the Source engine, as that's visually very distinctive, and was actually very helpful in informing sizing and proportions on things. If you're trying to hash out a level and ensuring everything is sized right, it just makes sense to have helpful template textures rather than flat grays as is the current norm, I think.
So, per the above image, you've got your 2x2 gray floor tile, and a 2x2 wall-with-door tile.
The images have the default scale and resolution information on them to let artists and designers better standardize texel density in their scenes and space stuff consistently.
I want to have a Basic set with your average floor, walls, doors, etc tiles. And then some other ones like stuff with tunnels, trees and the like. Basically a number of kits that should provide almost everything needed to block out your average level so you can quickly iterate during the design phase.
I'll be looking into some related utility functions for the Asset Browser too, like a 'replace all instances of this asset in scene' sorta deal. The idea being you could block out with the above kits, then when you're happy, you could make a 'final art' tilekit and just in-place swap the asset references to the final assets, so you don't even need to recreate the map with the final assets, which would save a lot of time.
All in all, I think this would be a good set of packs for people to jumpstart on.
And what better way to utilize asset packs, than a Project Manager!?
Oh you can manage my project anytime
Hm, that one got a little saucy.
So something I've been grinding at quietly in the background is a new Project Manager. I've mentioned working on it before, but I haven't really given any details. So here's a first look at it:
It's not super PRETTY or anything but functionality-wise it's pretty robust already.
Basic idea is it should be a pretty powerful ecosystem utility to let you get what you need set up and get working without a lot of extra fluff.
As you can see, there's an Engine Versions tab, Assets tab and Projects tab.
The general flow would be:
Get an engine build, generate a project. pull down any assets you want, install it into the project, and then start working.
With the realization that engine builds can come from sources that aren't necessarily the default T3D repository, there's the ability to add new versions whenever you want. There'll be the default T3D ones, of course, but you could, say, add one for a private repo for your project, and work from that. The new Manager has git and cmake integrated into it, leaning on those in the backend, so easily pulling down updates is as simple as clicking a button. Likewise for downloading the engine versions in the first place.
From there, creating a project is a simple matter. You go to your engine version, add a new project to it, and fill out some basic information, and it'll plug that into cmake for you(no more using CmakeGUI if you're a poor art-man who doesn't like fussing with all that busywork) and it'll generate everything for you. I should be able to add in a bunch of shortcut functionality for jumping straight into the editors, or launching your default IDE for the project solution file.
Then you have assets. I've mentioned it prior, but doing a full-blown store right off the back is a bit much from a managerial/infrastructure end of things. So for the near-term, we'll be utilizing a curated list from github. Much like working with engine versions, you'll be able to add your own asset repos or use the curated defaults. Then you can download them(again, via git, so getting updates on assets is a trifle, and the manager can link you back to the asset's github page and issues page), and then you can install them easily into your project of choice.
It's still got some work to do, but the basic flow is functional, so over the next 2 weeks or so, as the Asset pipeline gets it's refinements from beatdowns and feedback, I'll dial in the initial release of the Torque Manager and get it out for testing as well.
Ideally, outside of your power users like myself, the average community member or dev will probably just grab the Torque Manager, get their builds, projects and assets channeled through it, and have a nice, consolidated ecosystem to work out of instead of having to constantly chase down where stuff is, what branches/builds to use, how to install assets manually, etc.
As it gets ironed out, I'll add community features as well, linking out to these forums, the moddb, the wiki, documentation, demos, community news and the like, as well as converting old T3D resources/content to assets for integration into the Asset Library.
In the end, it should become a powerful nexus for people to easily jump to whatever end of the Torque ecosystem they need to get what they require and get working. With a little luck and a fair bit of effort, the days of 'i know it's out there, but I have no idea where' will be dead, and a new era of sheer productivity will begin
Anywho, that's all for today! Exciting stuff, isn't it! And if you figure the effort is neat and worth it, maybe consider allowing me to be a terrible shill and link my patreon here::
Even if you don't contribute to it today, I'll be overhauling it in the near future and will be sure to cross link stuff like these workblogs to it, so it may be a pretty convenient way to stay on top of stuff and help keep me fed
I'd stated a soft-goal of 'by christmas' in the discord(more specifically, I said if we miss christmas, I'd "flog myself"). If you guys can help with testing, or even better contributing fixes, that target will be entirely doable. Looking forward to getting this bad boy out there
Until next blag!