That time of month again, boys and girls!
So yeah, lots of stuff going on, whoof, where to begin...
Well, I suppose we could start with what's gotten into the engine since the last update!
So..uh, wow! Big shout out to @ Timmy
, @ Azaezel
, @ Johxz
, @ Bloodknight
, chaigler, @ Hutch
, @ LukasPJ
for their PRs, and thanks to several other of you guys for PRs we haven't had a chance to finish testing/merging yet, as well as the guys that keep the issue/bug reports rolling!
So now on to the delightful in-depth bits.Asset Browser
First iteration of this bad boy has gone in on the BaseGame template, and you can start really messing around with the asset, module and e/c flow with it. Good list of bits and features yet to get in there, but the core is in and it's decently solid.Entity/Component
The networking update(and a number of other tweaks and fixes) look to be performing pretty well. Still need to do a number of bits here too, namely integrating GameObject init-from-file so we can cut down on how many objects we need to create/stream, but it's looking good so far here. We can pretty soon start moving to the fun stuff with componentizing the existing game classes, as well as coming up with new, fancy componentsSystems
The MeshRenderSystem went in alongside the e/c updates, and it looks to be performing decently well and helping keep things clean. Some bugs to fix, but the notion is proving solid and a good basis for going forward and shifting most of the other components to similar configurations.
Now for future/RnD stuffs:Hitboxes
You may not have noticed, but the physics/collisions of the E/C stuff is pushed through the physics API for cleaner code and easier setup. This comes with a few caveats currently, one of which being that animated collisions are a bit of a....thing. It's hardly impossible, but it does take some extra wrangling to get the physical bodies animating properly on cue, so it's something I'd put off.
But, my game's needing hitboxes, and several other people have been wrangling with hitboxes, so it's a perfect time to have a random epiphany about how to deal with it. Namely: there's no obligation to use the physics API for raycast-only collision/testing.
Hitboxes fall under the functional perview of raycasting only. Technically, it expands to regular physics/collisions if you look at ragdolls or physical animations, but for the normal sense of hitboxes, it's seriously unnecessary to have the extra baggage just to test raycasts against for bullets or whatnot. So, I started looking at a hitbox collision component(which will be separate from the regular physical collider component) that implements hitboxes(based off the classical resource) This way, you shoot the mans, and the mans gets shot in a nice and easy fashion. Should be niceMesh Baking
I think I mentioned it with the talk about the MeshRenderSystem before, but one advantage we can invest in is static batching all our static meshes together at load time to get render performance boons for stuff that'll never change.
Likewise, one thing that was added to the engine a while back was the ability to select a number of objects and then export them as a singular mesh. This is useful for several reasons, but a big one would be to take a bunch of individual objects/models and bake them into one. This has a HUGE impact on render performance and cutting out a lot of overhead and drawcalls.
However, the implementation was limited as it only exported the highest LOD level and no collisions. I worked with @ Azaezel
a while back to start remedying that and he'd looped back around to it in the past few days. The collisions more or less export as expected and LODs also export(though we're puzzling out a grouping paradighm in the event that te different models have different LOD levels)
So in the end, you'll be able to say, draft up a house out of separate models(tiles, detail meshes, etc) and then select the whole shebang, bake it into a single mesh, complete with collisions and LODs and reap that sweet, sweet performance gain.The Render Pipeline
This would be the doozy for this update.
A hue part of why the PBR finalization is taking so long is because - and I don't know how many of you have gone rooting around through it - that large changes to the main render path is kind of a gigantic pain in the butt. And unsurprisingly, PBR - which requires a restructuring of the gBuffer at minimum - is a large change to the main render path.
So any time you want to go in there and tweak the gBuffer layout, or rename something to be clearer, you have to dance through a half dozen different files and remember where everything is. This obviously makes the last bits of a change, the tweaking and testing phase, a big chore.
So, I resolved to fix the crap out of that so it's a non-issue in the future. Enter Render Pipelines.
I'd touched on before the idea of the camera-driven render path, where instead of the GUI driving the rendering being updated, any active cameras are polled, told to render the scene from their perspective and settings, and generate a render target that the displaying GUI merely draws to the screen, allowing all kinds of neat things to happen.
So, building on that cleanup and streamline, we get to Render Pipeline(s). The idea is that instead of structuring everything like the code fairy can in and sneezed all over the codebase, everything pertaining to the main scene rendering passes through, or is implemented by, a core RenderPipeline class.
This will adopt controlling elements from various render bins, such as the lighting and shadow bins, as well as render kickoff and order that the SceneManager handles. The reason this is awesome is because not only does it allow us to trim the fat for stuff that's old and doesn't matter/help anymore, and not only does it make it all go through one place so it's easier to understand HOW rendering happens, but it also means that it's far easier and faster to tweak and reconfigure rendering behavior for the engine.
Expanding on that, I'm looking at having it script-definable for the setup and structure of the Render Pipeline, and being able to define multiple pipelines and swap them out on the fly as needed. Torque's already got a good chunk of that behavior with te ability to swap between advanced and basic lighting, but this would go further and be standardized.
So, you could, for example have a VRForwardRenderPipeline as well as the regular DeferredRenderPipeline. Each of those would tweak various settings, which other components of the engine can access in a clean, consistent fashion to decide their behavior as well. So if we look at the difference between DeferredRenderPipeline and VRForwardRenderPipeline, we immediately note by the name that one is deferred and one is forward.
So the rest of the engine knows what's going on, they could get whether the current RP has a gbuffer or not, and restructure accordingly, like so:
The render pipeline can easily report back that, in the VRForward's case, no it does not have a GBuffer as it's forward rendered, and the Deferred can inform it does.
It also will allow for a common function for kicking off a render in a clean, self contained way(which ties back to the Camera render path stuff) allowing less code duplication and just being easier to work with, as well as a singular place to set up all the targets of our GBuffer and various common shaders, rather than it being all sprinkled around the codebase.
I've actually gotten it to where the RenderPipeline is successfully replicating the current render path for everything except the reflections, which are still being a touch uppity. But the whole rest of the deferred render behavior works, and is implemented in a contained way. From here, the reflections need fixing, then a cleanup and separation of the existing render code so it's easier to comprehend and tweak.
Once that's done, I'll get the creation of all the GBuffer render targets moved over to it, as well as fields to control common elements like what shaders lights utilize(so different pipelines can use different light shaders, getting different behavior easily).
Once that's done, I can pretty quickly roll over the current PBR work to it, and that should make it FAR easier to do the last bits of tweaking to get that sucker locked down.Dark Theme
It's also time to stop waffling on the themes stuff. I'm just gunna pick an afternoon sometime in the next week or so and just port the old Dark Theme over, make sure it's all clean and kosher and get that PR'd once and for all Threading
Me and Az have also been working on stabilizing the threading stuff to make it ready to be checked in, so we're plotting for that to get locked down and in in the neat future as well. It's important to get the threading behavior correct on the first shot, because it's REALLY hard to debug bad behaviors after the fact.
I want to say there were more bits that we've started doing some testing and researching into, but I'm brain farting on it on that front, haha. So for now I think that's a pretty good layout of what's up and if I remember the other parts, I'll just append them on. Don't want anyone missing out on the sweet, juicy details after all
Until next time!