Silvan Hau

Yeah, that's probably a question for me. Probably the best question to start with, since I'm working on it pretty much full time. For the people who still don't know what the difference is, we've already published a lot of videos about it and other people have talked about it. But Gen 12 is basically our internal engine structure, the rendering architecture for how rendering works. And Vulkan is the underlying graphics API, which one day replaces the DirectX graphics API. And the benefit of Vulkan is pretty much performance. It scales much better on multiple CPUs and threads. So, well, performance. We all love performance and we've all seen what it can do in 3.17. If everything goes to plan, performance will get even better in the coming patches. So I'm very excited for that, especially after we shipped one of our first milestones in 3.17 for Gen 12. And I'm working hard on it to get it done.

So Gen 12, you can kind of split it up in two parts: all the scene rendering, like all the objects you see on screen, and then all the other rendering stuff like post-processing and compute passes and pretty much everything else. And the scene rendering was especially difficult to do, because we have hundreds of shaders and thousands of shader permutations and thousands of materials, and we need to make sure that everything works exactly as the legacy renderer. And we had a lot of issues and edge cases which you don't see during development. So just once you submit your code and it crashes somewhere, and then you take a look and see, oh shit. Okay, that's what happens. I forgot this. I forgot to add this. So I'm going to add this edge case. And so the first milestone was getting part of the scene rendering done. And for 3.17, that was the brushes. The brushes is what we call all the non-interactive static objects you see in game. And they're going through Gen 12 already. And the next step would be characters, ships, dynamic objects, and the planets didn't make it in 3.17 as well, though the objects on the planet, they made it in 3.17 as well with Gen 12, so happy about that. So once we have that, Gen 12 is almost complete. We still need to do all the transparent objects, which is still a huge task to tackle. But we started on that, and I'm very optimistic.

Well, ironically, a lot of the new technology we have actually saves you performance. So initially, it might even go the other way. It enables a whole bunch of features with things like mesh shading and variable rate shading, and sometimes not even hardware technology, but internal. Because we've restructured the renderer, we can now do certain things much easier than we could before. So there's lots of opportunities now for optimizations that we may not have had before. So it might actually be a double win after we can implement some improvements. There's features that I know there's questions about later, about DLSS or FSR and these types of technologies, which were problematic to implement halfway through when we're doing the conversion to Gen 12. Then they become on the table again once we've settled on a single new renderer. I don't think it's the end of the performance improvements once we've got to Gen 12. But there are also a few that would go the other direction and lose us performance. Future battle: we'll see how fast we can make it first before we worry too much about how much we'll slow it down in the future. A big focus we want to do is to make the engine scalable, so hopefully any new shiny things we add can be scaled up and down, ideally, so that you can keep the game running on the lower spec but push it hard on the high spec.

And completing Gen 12 is just the first step to a series of more optimizations we've already planned out. So expect much more to come after Gen 12 is done.

Yeah, we've got it on the milestones as if Gen 12 and Vulkan are a concrete thing that is not done and then one day is done. That's not quite true. I mean, it's useful for scheduling to make it appear that way, but it's not as precise as that. It's a continuous set of features. Even Vulkan will introduce new performance, or it might detriment performance in some areas, might improve performance in some areas. And as we learn more, we'll be able to get more performance out of Vulkan. So it won't just be we're done and we never look at this thing again. But the milestones we mention are a point of confidence when we think, yeah, that's like 99%. The biggest chunk of work is done.

Well, that's easy to answer. In fact, I posted a Gen 12 update and progress like two weeks ago on Spectrum. And initially, I didn't even plan to do that, because I didn't expect any performance benefits of Gen 12 in 3.17. But due to the rising amount of threads and people talking about these magical improvements in 3.17, and people wondering where that actually came from, I felt like I had to give an update. So that's what I did. The thing is, Gen 12 right now is only the brushes. They're rendering in Gen 12. But the big caveat is that with our rendering right now, we're mostly limited by the main thread and not the render thread. So there are two threads, and it goes very deep into engineering already, I would say. So for everyone who can't follow me right now, I'm sorry. But basically there's a render thread, which, as Ali said previously, is this kind of thing feeding the rendering work into the GPU. That, with the old legacy renderer, is really slow, because every frame we constantly check every state and see what objects we can render. And Gen 12 uses a different approach by just pre-baking the state in a small object. And then when we render, we just have the entire state ready and can just say, GPU, here, render this object. So the render thread, I tested it myself, with Gen 12 it's more than twice as fast. But if you're not limited by the render thread, which at least on my machine was mostly the case, it doesn't give you anything. So that's why I didn't expect any benefits and didn't feel the need to give an update. But in the future, with full Gen 12, that's another thing, because right now we have this mixed mode. We have objects rendering with Gen 12 and other objects going through the legacy path. There is actually a cost to that on the main thread, which is the bottleneck. Which means, what I would have expected, Gen 12 would have made it actually a little bit slower. But that didn't even happen. So I'm happy about that. But once we can get rid of all the legacy stuff and have full Gen 12, then we'll see the full potential, and I'm very excited about that.

I can give a short update on that as well. So for the people who don't know, DirectX only works on Windows. And Vulkan is created by the Khronos Group, which also created OpenGL. OpenGL is more an old graphics API, and Vulkan is the new modern graphics API. And these kinds of graphics APIs also run on various other operating systems. Vulkan is known to run on Windows and on Linux and even on Apple with an additional wrapper. It's called MoltenVK. And Christopher Bolte, he's very keen on the Linux port, so it's up top on his priority list. So I believe one day we'll see a Linux port.

The other thing I'd add to that, and this isn't first-hand knowledge but second or third-hand knowledge, is that people can already run it using the various layers called Proton and Wine on Linux. They can run the game now. I think there was an issue with Easy Anti-Cheat blocking that. I don't know if that's been resolved yet, but that was on Epic, I believe, to resolve. But that does work. But going through these layers that emulate Windows has a major performance cost. Apparently it's playable, some people say. But the use of Vulkan, I've been told, allows it to skip the layer it has to apply to translate DirectX into something usable. So even if we just had Vulkan and didn't implement native support for Linux, we would still get much better performance on the rendering by using these layers, because it wouldn't have to emulate DirectX anymore. It would just have to emulate any other Windows calls, with the input and the sound and things like this. But obviously the graphics tends to be a huge processor hog, so not having to do a translation between Windows code and Linux code will save quite a lot there, we're hoping. So it makes that route more viable until we get an actual official, native Linux client running.

Yeah, I talked to our developer who works on that. And right now, other priorities took over that task, so it's on hold right now. He's doing home office a lot of the time right now, and he has a super fancy HDR monitor in the office. Once he comes back, which is hopefully soon, and we're even going to move into the new office soon, which I'm super excited about, hopefully then he can take it on and finish it, because I'm very much interested in that as well. For everyone who doesn't know what HDR is, it means high dynamic range. Basically, it means colors from a monitor can be much brighter and more vivid than on a standard monitor like everyone's used to. And rendering, physically based rendering, which most engines do these days, already renders in HDR. And then as a post-process effect, all those colors get compressed into what we call low dynamic range, LDR. And that's what goes to your monitor, after some other fancy post-processing effects; gamma needs to be applied, but that's a story for something else.

So a bunch of support, I think, has been done. I think the last I looked, the tasks that were remaining to make it fully finished were three of them. So we have color processing, which is something the artists apply where they want to set the mood of a scene, like a blue-tinted sky. And they don't tint the actual sky when they want to achieve a mood. They render the sky physically accurate, and then, if you imagine, a bad example, every nighttime scene in a film is filmed in daylight and then they just make it blue. That's an exaggeration, but that's the approach. So sometimes the artists use these things, usually quite subtly, but that process is currently mapping one low dynamic range color into another low dynamic range color. The process becomes a bit more complicated when you're dealing with high dynamic range colors. When they say they want to turn a white sky to blue or a blue sky to white, it gets more complicated. There's now millions of shades of white, millions of shades of blue. Did you just mean the very bright blues or the ultra bright blues or the extremely bright blues? So that process needs to be changed, and it involves changing the art pipeline a little bit and how they author the color correction. And the two other issues: we have what we call the game post effects, which are not the critical rendering ones like color correction or our lighting and blurs and things like this, but like when you've been shot, blood appears on the screen, or you're blacking out. These types of effects all run in low dynamic range, so they all need to convert to high dynamic range so they don't lose quality. Otherwise, they'll appear very dull if we don't do that. And then the final one is the more open-ended one. When people say this game has a good HDR implementation and this game has a bad one, like Silvan said, we already render the game in HDR. The problem is even the HDR monitor, it's high, but it's not infinite dynamic range. If we had infinite dynamic range, we'd just give you the image we rendered, but that's not the case. What you have to do is query the monitor, find out what range it's got, and make a best guess of how bright you think you should render the image and how you should color correct the image, and then probably also give some sliders for the user so they can tweak it themselves. That can be a hugely subjective point of view, and like I say, different games get either praised or beaten for how amazing or terrible their HDR implementation is. But it's really just that last part in the pipeline that people get upset over. So we need to just balance that and make sure we expose the right knobs and tweaks so everyone can get the image they want on their monitor.

It doesn't help that there's probably a dozen HDR standards, or a half dozen HDR standards.

Yeah. Lots of color spaces, lots of different ranges, different ways of interpreting things. It's a bit of a minefield.

I think that's exactly what Jonas mentioned, I believe. So we already have this kind of, what we call it, interior shader in our engine, just as a standalone shader right now. And I actually didn't know about it until a month ago, when I saw it in-game because I had to fix a bug on it. So I've seen it live in the engine, and I was already impressed. It looks pretty damn cool. And we're already experimenting with it in engine right now. So I'm optimistic that we're going to see it very soon. But it's mostly the art side now who has to implement it and test and iterate on it and make sure that it looks good. From the technology side, everything's working, looking good.

So that's at the point where it's ready for artists to start playing with it, and then they're going to discover all the bugs and all the problems with it, and then they'll come back to you to fix it.

Exactly, yeah. I mean, they're already playing with it, and I'm excited to see it in engine. It's definitely going to give some more life to those buildings when you can actually see inside.

So I'm using an ultra-wide monitor myself, so I know about the issues with Star Citizen. Unfortunately, we as Graphics and Engine don't have too much to do with that. It's more a question for UI and how they implement it, especially in the Building Blocks system, how the UI scales with all those different monitor resolutions. I'm not sure. Maybe Ali knows a little bit more about that, if there are priorities on that?

No.

We've actually got something with the UI team scheduled in the next two months, I think.

There's a few graphical things with ultrawide that we sometimes need to fix or improve the performance of, or sometimes the quality; maybe our post effects aren't always amazing in super wide. And also, if you're super wide, depending on how we deal with the aspect ratio, you can have more objects to render and obviously more pixels to render. Gen 12 and other optimizations like DLSS and things we've talked about would all help there. But in terms of just making it a fun experience, with where you position the HUD and the chat windows and stuff, it's all on the UI team in the end, and we don't really have any control of that.

Yeah, I'm seeing that too. The thing is, that's mostly decided by art, how they want to set it up. Of course, it's measured based on performance. But Gen 12 and Vulkan will improve performance, and I think we will scale it up at one point. But I'm not sure what exactly is planned there, if there's anything official yet.

Yeah, plans, not concrete, but definitely discussions with the Planet Tech team about how we can take things one level higher. At the moment, basically, each object is considered an individual object in the scene. It's spawned and we manage the position of it. We do have some small-scale grouping. We might group five or 10 objects together. But what you need if you want to, say, render an entire rainforest is the ability to have millions of trees. And just having the concept of an individual tree exist means that becomes beyond the reach of a sensible-speed computer. You need to have the concept of: this is a patch of forest that might be a kilometer wide or 10 kilometers wide. And the trees either never existed individually, only as a group, or they are being spawned extremely quickly and then merged into one Uber clump that we just have to submit to the GPU, or not even submit to the GPU, but just render on the GPU without any CPU involvement. But the current approach of having one object constructed and then sent to the GPU each frame just doesn't scale quite to the level we need. Gen 12 will give us a big boost on what would be possible with the current system. But there's plans for the extreme modes, we'd call them, like the rainforest, where you can just see for miles and miles of trees. That needs something slightly different for that to work.

And all these objects on the planets are already using a more specialized path to be rendered much quicker than our usual objects, like all those brushes. But as Ali pointed out, if we want to have really dense, lush forests like you've seen in Microsoft Flight Simulator, there's definitely a lot of room to improve, and it's definitely something we're looking at and aware of, and hopefully we'll implement something in the future for that.

Well, as I already pointed out at the beginning, we want to finish Gen 12. So there are a few more milestones we have to finish. The transparent rendering, that's the biggest one. And once that's done, I expect all the other things which are missing, which are more like a few compute passes, like Planet Atmosphere stuff and compute skinning and a few other things we've probably overlooked so far, to be finished. Then Gen 12 is done, and I'm really excited to see how much performance we can get from that. After that comes Vulkan, which is not lagging too far behind, because in general we're developing Gen 12 and Vulkan in parallel, and Vulkan is just lagging a little bit behind. So once Gen 12 is done, it shouldn't take us too long to get a first version of Vulkan working.

Anything you want to add to that, Ali, Jonas?

We've got these guys on Gen 12 on the engine team. We've got about half the graphics team on Gen 12 as well. The ones that aren't on that are working on a number of features. Mainly, there's a bit of a backlog for SQ42, the critical features we need for that. They'll obviously feed into the PU as well. There's very little that would be specific to Squadron; it's just who is the prime need for each feature. But there's a few features in the works for them. Some research for longer-term features like jump points, the graphical implementation of that. Things like improving the water effects are on the near-term goals as well, and unifying them. We have a planet ocean shader. We have a water volume shader. We have a river shader. These things all need work and love, and to be integrated with the VFX as well. In the transition of our engine over to all the improvements we've made with planets and stuff, we've lost splashes and dynamic waves and stuff like this. We need to reintroduce these types of technologies. But mainly we have half the team on Gen 12, and when that's done, they'll be on Vulkan until that is running buttery smooth. And even then, that team might then look at the DLSS/FSR type approaches, and only then will they join the rest of the team on the general graphics features.