Work Blog - JeffR

196 posts Page 20 of 20
Online Duion
Posts: 881
Joined: Sun Feb 08, 2015 1:51 am
by Duion » Fri Jan 05, 2018 11: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.
Steering Committee
Steering Committee
Posts: 777
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Fri Jan 05, 2018 4:07 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.

User avatar

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! :D
Posts: 70
Joined: Sat Feb 07, 2015 1:29 am
by HeadClot » Sat Jan 13, 2018 12:29 am
OK, This post has taken a little bit longer than expected.

Anyway - My follow up questions for @
User avatar

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?

Answers -
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..
Steering Committee
Steering Committee
Posts: 777
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Sat Jan 13, 2018 3:13 am
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.
Posts: 70
Joined: Sat Feb 07, 2015 1:29 am
by HeadClot » Sat Jan 13, 2018 4:43 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 :)
Site Admin
Posts: 361
Joined: Tue Feb 03, 2015 7:25 pm
by LukasPJ » Sun Jan 14, 2018 4:41 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:
196 posts Page 20 of 20

Who is online

Users browsing this forum: No registered users and 3 guests