Mid-October workblog time! (Which should've been last month, but chasing down bugs like memleaks and straight up crashes before I wanted to post caused delays, so...whoops!)

So, how's it going everyone? Time for fanciful development news.

First, lets go over what all work has happened thus far since the last workblog:

76 pull requests merged in, which had over 164 changes which ranged from bugfixes, to improvements to additions.

Notable examples include:

• Updating SDL to latest
• Steve passing along a fix to correct render issues for the ribbon particles
• Preference settings(which will get integration into the options menu soon) for forcing static object fadeout at a distance, as well as limiting the number of local lights renderiable at a time, and if they fade out over distance as well. These can potentially help a lot in very object-dense scenes with lots of small clutter stuff that doesn't need to render at a distance
• Some better default values for local lights, and cleaning unneeded fields
• Fixing of gamepad inputs
• Various shadergen cleanups
• A whole metric butt-ton of fixes, improvements and QoL changes for the asset workflow
• Ability to better control script queue ordering between modules
• A crossplat option for 'open in browser', which could see a lot of use in jumping to documentation
• Improvements to baking of meshes
• Adds populating of a level's utilized assets into it's dependencies list to ensure everything preloads as expected instead of trying to do it at the last second, which could cause scripts executing during object creation and lead to variable corruption
• Settings files are now properly sorted(A small change, but it keeps the layout of the settings.xml and asset import config files consistent making them easier to catch up on changes)
• Re-implementing SIS files for the importer so there can be special-case overrides for any given file type
• Fixes the resource change detection for TSStatics, so if a shape files is changed, it auto-updates the objects in the scene
• Fixed several potential memleaks and one confirmed one that could balloon the mem usage pretty substantially over time
• Misc improvements to asset import pipeline stuff, such as suffix parsing improvements
• Shuffled some gui profiles into core to better standardize them
• Created a number of macros to wrapper around defining and setup/usage of assets(image asset for now, but others later). This is so you don't have to define a bunch of supporting stuff in a given class over and over. Basically, convenience and code templating thing.
• GL and GCC compilation fixes
• Integrated the old MeshRoad Profile editor, so you can have more control over the shape of the meshroad
• Added guiRenderTargetViz control, which lets you specify any given render target and display it to a GUI control. Minimal direct use currently, but useful in debug operations, and in the future could drastically simplify doing stuff like picture-in-picture displays or multi view GUIs and the like.
• Fixed a pretty gnarly memleak, so we're memory stable again.
• Lukas got his C# project caught up to current BaseGame so we can better test the cinterface changes(and soon people can play around with all that too)

For some of the bigger changes worth going into more detail:

First, Mars contributed some very important improvements to window and resolution handling.

This adds in Borderless window mode, as well as the ability to set in the options what display(if more than one is detected) the game window should be on. Additionally better handling for what screen resolution should be in play based on window mode(ie, Borderless is always the desktop resolution) as well as ensuring display options apply properly.

I added handling to disable options fields if they are non-applicable to avoid confusion

Secondly, an update to both PostFX organization, Integration, and Editing behavior

All stock PostFXs and their shaders are now safely tucked into the core/PostFX module. Easier to find, easier to edit, and the shaders aren't in a completely different module.

The loader logic was tweaked slightly as well, so that the levelAsset has a field which indicates what the postFX file is. This requires less manual logic for 'lemme go dig around for a posteffectpreset file' and should be a bit more reliable.

Additionally, the PostFX editor saw some fairly big updates, both in how its accessed, and how it works.

You can now either edit the default postFX preset, or edit the current Scene's preset, as seen here:

The editor now better integrates into the PostFXs themselves, as well as auto-applying changes as they happen which is much, much, much better for dialing in how they impact a scene.

Importantly, you'll note that the list of PostFX's displayed in the editor there looks kinda...lean.

This is because it now only displays active PostFXs rather than the entire registered library, which should help cut down on confusion about what PostFXs are actually active and impacting the scene.

Adding is as simple as pressing the green plus button at the top and then picking which to add from the list that auto-populates with all registered postFXs

And then selecting from the list on the left to edit a given postFX:

Removal is as easy as selecting the PostFX in question in the list and pressing the red minus button.

You may also note a bit of change in what PostFXs are there. Most are the same as always, but a few tweaks happened to make things a little more consistent and interop-friendly, such as moving the LUT color correction logic out of HDR and into it's own. I also added a simple Sharpen PostFX, and integrated a Chromatic Aberration PostFX.

We also recently shifted over to utilize 'ORM' formatting for the PBR image maps.

In order to better integrate with tools, and because GLTF assumes ORM, and it's the closest thing to an industry standard for the PBR map, we're shuffling it around internally to work as ORM as well. What's ORM? It stands for (Ambient) Occlusion, Roughness, Metalness. It's basically the PBR image maps arranged in a specific channel order. GLTF and a handful of engines assume for it in that order, making it the closest thing to a standard, so to keep it simple, we're doing the reorg.

Likewise, we were operating with Smoothness being the front-facing value instead of Roughness. This is - similar to the PBR channel order - sorta a 'eh whatever works', but Roughness is a bit more standard, so we're going ahead and making that the front-face standard as well.

Internally the math assumed roughness anyways, so it isn't a huge change principally.

Touching to the above, we'd noted some oddball behavior when adjusting roughness and metalness values, so with Timmy's fantastical eye for that stuff, he was able to spot some problem areas with the logic and our BRDF image. The changes he passed result in much, much better behavior across the full roughness/metalness ranges and thus looks much more correct on any given material. Huge props there.

I had also mentioned some crashes and stuff. There was a bug that snuck in with the probes where baking them could cause crashes. It hit some hardware more consistently than others, and was a right pain to track down. In the end, though, I put up a PR with a big update to the probe handling. Before, you could have up to 50 active probes, and they would render all in one big go. It worked, and it guaranteed consistent performance, but a lot of scenes don't utilize anywhere near than many probes in your line of sight.

So I shifted the logic to where you have registered probes, and active probes.

You can have up to 250 registered probes in the scene now, which is quite a lot for anything other than a big open world deal(and you can always unregister them selectively as needed), and an adjustable amount of active probes. The default is 8 but it can technically go all the way up the whole 250(though that's not recommended for performance reasons).

One of the big advantages outside of the basic performance consideration of not needing to actively render as many probes at once, is we can now lean on culling to ignore probes you can't even see, which just compounds the performance gains, and be smarter about which ones to bother with. It calculates and picks the best probes based on the camera's position, and I'll be adding an 'influence' value for more artistic control so certain probes can be noted as more important than others.

All of this together means it selects the best probes and renders only those up to the set per-frame limit(which again, is adjustable for a given game's needs) yielding the same results in terms of blending between probes, but much smarter and targeted selection of which ones to render, yielding improvements in performance.

We also fixed it finally so that surfaces that are metallic will correctly render in the baked cubemaps for probes instead of the flat black they were before, which should yield more accurate results in the reflections.

While the above probe reorg and crash chase-down sorta dominated the last 2 weeks(crashes are a pretty big deal, so it was important to get out of the way), we can get back on the track of getting the asset integration with the game classes sorted out. I mentioned the utility macros added for image assets, which are most recently utilized by the materials class now.

This has streamlined quite a bit of code and makes everything Just Work, and between it and the asset usage in TSStatic, we're feeling pretty confident in finally moving forward and adding asset integration for the remaining classes. This is probably the last big obstacle for 4.0, especially as the general asset pipeline is proving to be fairly stable at this point, and PBR is getting a good workout in several projects and what minor issues crop up are getting plugged quickly. The issues list I've got keeps creeping downward, and things are looking quite nice  

For a parting bit, one thing we also added in recently was a Prototyping module. It has a number of color-coded materials designed to be used for certain surface/object types and be visually distinctive so as to help understand the map/design space without needing to worry about the fine texture detail. Additionally, a number of primitive objects like a cube, cylinder, etc are in there.

However, we also needed a size reference stand-in, and I thought, who better for that than our very own Kork-chan?

Definitely won't be as long for the next workblog, and I imagine we'll have a number of modules to try, art to ogle, and a new test build up quite soon, so stay posted!

-JeffR