Namely, post holiday-time, which is always a delightful time of 'oh hey I have time off I can do game de-oh right, inlaws and constant forays out into the real world instead.'
Combine that with a little post-holidays sickness and the post update I wanted to roll out around new-years got delayed. So. Here we are!
I know the gameplan was to get 4.0 out in 2019, but between PBR taking longer to lock in than anyone expecting and loooots of excellent feedback on tool/asset stuff meaning a lot of additional polish time that came from the Preview build, it ultimately slipped a little. But have no fear, because there's not all that much big chunks of stuff to chisel away at at this point.
For example, outside of a few lurking bugs reported with some odd baking/loading behaviors, particularly on linux, PBR has proven to be rather reliable since the last update with no major changes needed or problems cropping up.
I also took the opportunity to nab a subscription to MegaScans which allowed me to import a photoscanned cliff model and the results look quite nice:
But more on that shortly.
Ultimately, I see 50+ changes that went in since the last workblog so we can walk through some of the big bits within that(because honestly, there's enough stuff that if I don't just focus on some of the big chunks, this workblog will be like 10 miles long instead of only 1)
So, PBR is good outside a few remaining derps, as mentioned.
Progress on assets has been good. A lot of feedback has been acted upon to make the useage flow better, but most importantly better flesh out the weak spots of the import process.
I've detailed how it worked before, where you'd drop something in to import, it'd use the import config to discern what you were going for and smartly try and process associated assets in at the same time to make it as automagic as possible.
Unfortunately, there's a number of things that can trip this up. Image names being distinct from the material names defined in the model, for example, utterly break the lookup process.
If the different image maps have different naming conventions, or use a non-standard convention to discern the image map type, this too could break the import.
So on complicated models, importing them would often break down where it'd miss images, and then you have to do a second step to import those, then have to edit the materials to assign them to the right fields, and you're basically back at square one.
So I took a lot of feedback as said, and ended out with a much, much more robust import interface:
As you can see, the layout shifted a good bit. Now we have a heirarchial tree view, complete with icons to quickly at a glance indicate what each asset is of what type, and it's heirarchy.
The RMB popup is context-based, so when I did it on the material(because it failed to detect any image maps automatically due to naming shenanigans) I was able to pick what sort of image map I was attempting to bring in associated to that material.
You can also now add more importing assets in a 'session' which wasn't feasible before with this approach.
Beyond that, you now get immediate information about each given asset by clicking on it in the tree, which allows much faster understanding of what you're working with. In the event of any warnings or errors, the icon on the tree will adjust to reflect which assets are having a problem, and selecting it to inspect it will have the information in question about the problem displayed in the 'Status' field, again removing a lot of questions about what's going on or what's having an issue.
And to FURTHER make it harder to lose track of exactly what the importer is doing, we now have a log:
So pretty much any given action performed by the importer in a 'session' is logged out there. Assets auto-pruned due to config rules, issue resolution, adding new assets, all recorded there. So when something doesn't show up as expected, you can better understand why, rather than just guessing it went all stupid on you.
Beyond that, expanded the editor settings relating to assets, so you can easily edit the configs instead of needing to open the importer window first:
Which now has a more robust editor interface as well:
(Similarly, the PostFX Editor got a layout update to be like the above:
so it's easier to navigate. Plan is to have a lot of stuff adopt this layout because it's so much easier to navigate/edit stuff like that)
So. Interface-wise the asset and import workflow is in a really good space now. So what's left?
Mainly, I'm finishing standardizing out some of the 'actions' in the asset browser to be managed by the given type rather than global functions. You know, like renaming or deleting assets. Since each asset type has different loose file structures or specific modification behavior, having each asset type have the ability to handle those actions makes more sense and keeps things better organized. So I need to finish that.
After that, the last BIG thing, really, is finishing 'Assetification'. Or going through the engine and any place we have a field or lookup or add action for grabbing a file, such as an image, shape or animation, have it have an asset field companion to it. So any new stuff will work with assets, but legacy objects and classes that convert up doing instantaneously explode either.
Only a few dozen fields or the like rigged up that like, so it'll take a bit of time, but it's nothing grueling. Once that's done, the engine should be more or less completely compliant to the asset workflow.
After that, there's a spread of small remaining todos, fixes and the like, but honestly that's basically the bulk of the work done. Everything has been just local bugs, no major feature NEEDs have cropped up that cannot wait for a follow up update.
Incidentally, according to my issue track list I've been maintaining since the Preview went live, 192 different issues had been added to it. Lots of them are 'this can wait for a follow up update' of course, but the majority of them are knocked out at this point, which is most excellent news!
So once that's done, we can do a last pass for anything that NEEDS to happen for 4.0 to ship, but honestly outside of making sure everything is happy cross-plat, I don't think we have much to worry on there.
Once 4.0 is on a lock, we can finalize the migration to the new main repository home: https://github.com/torque3d
And I can start working on documentation, examples RPKs and assets for the Asset Library so the Torque Manager will have plenty of material for people to immediately jump off with out of the gate.
And speaking of the Manager:
Showing off an example I did a bit ago where I pull down a binary build of the Preview version, make a new project from it and launch it all from the Manager.
Only real thing to do for it is get the asset handling working and all the preference stuff and the basic mechanical features are all done. So that should go live for testing here in the near future as well and I think should help everyone a LOT, especially with keeping tabs on all your builds and projects
Tomorrow, I'll post an updated Roadmap so we all have a good idea of what's cooking once 4.0 goes out the door, so that'll be nice and exciting
But what a wonderful job, at this point I already wanted to have a lot of programming experience to help you. lol I'm studying hard ... I'm very happy to see your wonderful work ... I see JeffR as one of the foundations of this community. One day I'll be ready to be able to put my signature on Torque3D.