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.
@ HeadClot1. 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!