### Work Blog - JeffR

#### Re: Work Blog - JeffR

Duion
Posts: 1208
Joined: Sun Feb 08, 2015 1:51 am

It is mostly just Jeff alone who maintains the repo, so don't expect too much.

I think we could need some more people in the steering committee as almost all other members seem to have bailed out.

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 900
Joined: Tue Feb 03, 2015 9:49 pm

I'm the one with write access, but we have several people acting as the core driving direction of the engine, so don't worry on that end.

1. Is it safe to assume that with the Vulkan wrapper that we would be able to target mobile platforms such as Android and possibly iOS?

It's an option in the future, but I'm going to say that as of the launch of 4.0, no those platforms won't be supported. In addition to the graphics API, you still need the platform layer stuff so the engine can interface with the file system and whatnot. SDL *does* enable that, but we haven't investigated into those channels at all yet. But you are correct that it would fundamentally open the path and we could potentially look into it in the future.

Also, iOS requires Metal for it's modern graphics API. Unfortunately, Apple has deigned to not support vulkan and instead do their own close-to-metal API.
Metal support is something notionally planned, as that'll help render performance on MacOS as well, but again, OpenGL/Vulkan would be the immediate focal point of GFX3.

2. Are there any plans for any networking improvements slated for T3D? I ask this as I am looking at making some form of large scale persistent online game with T3D.

The core system is largely untouched currently. With the entity/component stuff, there's already a good bit of work to making a given packet update as lean as possible, but if we're talking MMOs, those tend to require *very* special handling. You're going to have to provide a bit more information about your networking needs for me to know if the e/c stuff already plotted would be sufficient, or if you'd have to have more improvements to fufil the requirement.

3. Are there any plans for Visual Scripting? (Similar to UE4 Blueprints or Lumberyard Script Canvas)

Most likely. It's not a focus, but I've been planning for a long while to have a visual shader editor(similar to the material editor for UE4), and this could be branched off to support generation of gameplay scripts as well in the future. Not an immediate target, but it has potential.

4. Will there be any form of node based material or Shader editor?

As per above, yep. If you go back through the workblog, you'll see I've already begun working on a visual interface for material editing, as well as a visual state machine editor.

5. Is there any pre-compiled experimental branches that I could check out?

John's had some builds, but those are primarily the development builds and whatnot. For the more 'still broken and WIP' stuff, not currently, though I was planning to assemble an up-to-date R&D branch this weekend. I can make a compiled binary of that when I do if you wanted to poke around at it, just be aware it's gunna be 30lbs of buggy WIP-y jank in a 10lbs hat

Also, I think I saw you make a passing mention about BGFX at some point, too? To elucidate on that and why we're looking at a GFX layer we're writing and now BGFX:

We actually have looked into BGFX a good bit, and while it is indeed a largely well done system, because it's trying to support what feels like every API and platform that has ever existed, it kinda explodes the fundamental complexity of the system. D3D9 is MILES different in how it runs, structures data, how/when you do draw calls, etc from Vulkan or D3D12, for example.
To make all that behave, the underpinnings are comparitively more complex and have to do more and more voodoo for the toplevel stuff to play nice, and it gets harder for us to track through things when stuff goes wrong, etc.

It also has it's own shader language, so any knowledge people carry on from GLSL/HLSL goes out the window as you have to learn the BGFX shader language(obviously that's hardly impossible, but it's just one additional step to get things to happen).

It also doesn't save much effort in the end either, as we're going to have to do rewriting to get any new GFX system working, whether it be BGFX or GFX3 and at least with GFX3 it'll be lean, do exactly what it needs to do with no extra fluff or overhead spent on trying to handle logic on packaging the data for whatever API you're going for.

TL;DR It's definitely a good API, but we feel that we'd be a little better served with a more purposefully written system we're fully familiar with that doesn't carry as much baggage and requirements with it.

If you cannot tell I am excited for 4.0 and beyond.

I can, and I am too!

#### Re: Work Blog - JeffR

Posts: 80
Joined: Sat Feb 07, 2015 1:29 am
OK, This post has taken a little bit longer than expected.

Anyway - My follow up questions for @ JeffR

More Questions -
1. What is the plan for Virtual Reality in T3D 4.0 and beyond? I have a windows MR headset if there is anyway I can help out let me know.
2. Has there been any news on the upcoming C# Support?.
3. Any plans for a dark theme for the editor? I know there was one a while back not sure what happened to it.
4. Are there any plans for GPU particles?

1. Android and iOS support - The reason I asked about this is AR is going to be big in the next few years but it is going to take time to mature. We should consider adding Android support and iOS Support IMO.

2. Networking Improvements - I am looking into making a MMO with T3D. So spinning up and down servers as needed, crossing server bounds, etc.. I am pretty sure the Life is Feudal devs have already solved this though. I have yet to reach out to them. Although I am really curious how they managed it and If they would be willing to share that code. If not that is OK..

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 900
Joined: Tue Feb 03, 2015 9:49 pm

1) I think the primary focus is going to be towards the OpenVR library for now, as most things are looking to be supported through that. Custom libraries can be supported alongside that as needed, of course, but I think the primary focus of core dev'll be with OpenVR.

No idea if Microsoft's stuff works through that yet, I haven't checked.

Usage of VR in a project will definitely get easier with the E/C stuff. I'd already started preliminary research for it, and the plan is to have VR-specific components such as VRCamera and VRControllers that can be applied in and you're off to the races without needing to do all the script tweaks manually.

2) Lukas has done more work on it, ya. He's been having a bit of a time getting the variadic template update for the console system to play nice(as different compilers reorder the variables different ways, so their order can't be so easily assumed) but he had gotten his prior work updated to the current builds.

To my knowledge, he's mostly just trying to hammer down the reordering stuff to get it to be nice and consistent now.

3) Yes, Dark Theme will be the standard, but beyond that I've been looking at supporting "Themes" for the editor - aka where you set colors in the editor's preferences, save, reload the editor, and the new color scheme is applied.

An example of the WIP here:

Obviously not done yet, but the idea would be to have a few default themes, then the ability to just select colors for the different elements(background, highlighted text, etc) and be able to save those settings for a customized theme that saves out with the editor settings.

4) It's come up, yep. With the current GFX, it's kinda weird to do, but it's been an example of what you can do with the new buffers-based stuff we've been looking at for GFX3. So when we do GFX3, GPU particles is likely to be one of the early things we give a go at because it's a good test-case.

Android/iOS Support: Yeah, fair enough. As mentioned, not a short-term focus, but I've no opposition to supporting those platforms down the line if possible. But we definitely have higher priority things to work on for now

2) MMOs are tricky and weird. There's lots of stuff you'd do for an MMO you wouldn't do in any other type of game project. I think how intense that weirdness is is based on the type of game it is(turn based is way easier than an MMOFPS for obvious reasons) as well as the predicted player counts.

Having a zone/instance system a la Guild Wars is WAY easier to do in any regard compared to the "lets have 50,000 people on one server" for WoW and the like.

We'd mentioned your inquiry to the dude from LiF we've been working with on some improvements and he said that if you're shooting for a 'real' MMO in the thousands of players per server range, T3D probably isn't the best bet as some of the networking behavior isn't geared towards it.

That said, it did get our gears spinning for places of improvement for the networking behavior, such as better compression, standardizing bitcounts for optimal packets and the like, so the conversation's going to yield some improvements either way, but I think I'd agree. T3D's got a solid, versatile network model, but it's not designed for 'lolwtf' levels of players per server like WoW or similar are. If you're shooting for those players counts, it's gunna be weird.

If you're shooting for more "moderately massive" style, where you have zone servers with more reduced populations per-server and instances and stuff, then it becomes a lot easier to manage that sort of thing. Definitely doable then.

We've already been working with them to get a number of improvements to the engine rolling, so I'll make sure we learn what we can from them on their networking side as well.

#### Re: Work Blog - JeffR

Posts: 80
Joined: Sat Feb 07, 2015 1:29 am
Hey Jeff,
Thank you so much for the clarification on the all those things.

As for the MMO bit -
I am aiming for the zones and instances approach across multiple Virtual Machines not a one massive "lolwtf" server.

The hard part for me is to make the right servers work together when a player or players cross a server or a zones bounds and moves into a new zone. Not sure if my terminology is right here. Hope that explains my intentions

#### Re: Work Blog - JeffR

LukasPJ
Posts: 402
Joined: Tue Feb 03, 2015 7:25 pm

To expand on the status of C#, it definetly seems to be working. The C# code-generator has to be updated, and cleaned and stuff like that. But it isn't really all that important to get C# "ready". The main issue is to get T3D to support 3rd party languages interfacing with the engine.

That part of the code is a WIP, it's in a state of "working, but not ready for release". I've been having trouble finding time to examine and figure out what parts of the old C-Interface should be left, and making the code I have written for an updated interface nice and clean.

Luckily, it's actually just a minor change. If we can agree on how the C-Interface hooks into the engine, then it's really just a minor change to the engine, so it doesn't have to be bundled in a huge release like 4.0. It doesn't change how the engine works really, it just makes some minor updates.

C-Interface update PR: https://github.com/GarageGames/Torque3D/pull/2136

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 900
Joined: Tue Feb 03, 2015 9:49 pm

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!

#2128
#2151
#2059
#2156
#2126
#2134
#2131
#2133
#2094
#2170
#2183
#2180
#2166
#2165
#2171
#2182
#2188
#2187
#2184
#2185
#2189
#2190
#2196
#2198
#2205
#2203
#2206
#2157
#2202
#2159
#2158
#2162

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 components

Systems
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 nice

Mesh 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:
if(RenderPipeline::get()->hasGBuffer())
{
...
}
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

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!
-JeffR

#### Re: Work Blog - JeffR

Posts: 80
Joined: Sat Feb 07, 2015 1:29 am
Awesome work as always. Got a question though - I currently want to try out 4.0 even though it is currently undergoing allot of work. What version of Visual Studio should I use and are there any guides to compiling the engine?

#### Re: Work Blog - JeffR

Timmy
Posts: 371
Joined: Thu Feb 05, 2015 3:20 am
Awesome work as always. Got a question though - I currently want to try out 4.0 even though it is currently undergoing allot of work. What version of Visual Studio should I use and are there any guides to compiling the engine?
Visual studio 2015 or 2017 work perfectly ok (both 32 & 64bit). Check the wiki for cmake instructions (section 3, section 1&2 are no longer valid), the pics are a little old but still valid. Just beware the development branch as is today is quite buggy, by all means have a tinker around with it but i don't recommend doing anything serious with it. It contains no pbr work yet either.