Interdimensional Games Inc.

Consortium: The Tower Early Access ALPHA 1.5 is live. Lots of bug fixes and general gameplay and content improvements and polish. Estimated amount of gameplay for Act 1 is 15-20 hours viewforum.php?f=157

Not only will Vulkan work on Linux, Mac, and Windows, almost all cards tested show improvement with it over OpenGL (~5%) and huge improvements using AMD cards (~30%) in Doom. Unreal Engine also has support for it.

As a graphics programming student, I feel that I have to point out that Vulkan isn't just a peripheral to be supported like Oculus Rift -- it's a straight-up rewrite of the graphics pipeline, requiring a better card and different drivers. If the game already exists to any extent in another graphics system (DirectX, OpenGL) then porting to Vulkan is almost as hard, if not harder, than porting to another operating system without abstraction libraries. In layman's terms, porting a Windows-only game to Vulkan would take as long as porting that game to a Mac without WINE.

Basically, it's not a drop and play solution, no matter what engine you're working in, sort of like how OpenGL isn't a drop and play solution for DirectX. There are tradeoffs.

Oh, probably the worst part is that supporting Vulkan means not supporting OpenGL or DirectX in that build. 3D graphics are a pick-one system for the underlying graphics card access. To keep support for older systems with no Vulkan, they'd need multiple builds maintained simultaneously, which means double the bugs and double the work.

Sorry if this post came out a little rambly; I'm pretty tired. Anyway, just my two cents on Vulkan support: it has to be a basic goal of the project, not a late add-on. OpenGL (or DirectX, though that's Windows dependent) will work just fine on Vulkan cards for the foreseeable future, so why lose backwards compatibility? I say don't bother.

Not sure if IDGI is using a custom deferred renderer again. If they are, that creates a huge amount of work on top of everything else meaning Vulkan support is unlikely. If IDGI is sticking to the UE4 basics, compiling the game in 4.17 might be enough to make the Vulkan option available.

At IDGI, I was responsible for building a portfolio of shaders and modifications to the Source Engine in order to create a cell shaded toon-like art style for the game Consortium. During my time here I implemented:
• Deferred rendering
• Outline shader using depth & normal buffers
• New toon-like bloom shader
• Dynamically generated skydomes
• Light culling performance enhancements
"
This is backed up by the description in old copies of the Consortium game one store page:
"*Built with a modified version of the SOURCE engine utilizing Deferred rendering, explore ZENLIL, a living and highly interactive environment with complete freedom and agency. Includes turbulence and non-scripted decompression events!"
And, as it turns out, Source itself already has deferred rendering anyway, from the Wikipedia page for Source:
"Pre-computed radiosity lighting and dynamic shadow maps.[15] Deferred lighting is supported on consoles."

The Source used in Consortium game one was definitely a deferred rendering engine. It's the only way they could have supported every single bullet and grenade being a light source, as they did. Given how different Vulkan and OpenGL are, I don't think they'll be able to use Vulkan without a level of work beyond their capabilities. Atop that, Vulkan is only available on newer cards that easily have the power to run Consortium. There's no appreciable benefit to adding Vulkan to the game, at least from what I can see.

It really all hinges on how broken the stuff they made specifically for the game is when ported to Vulkan. If they stayed within the confines of UE4 (which I know isn't entirely the case), it may work with little/no modifications.

okay I totally believe you. The only thing strange about this it, that you can use MSAA in Game One ... which isnt supported on most deferred renderers (in fact deferred rendering opened the path for the various rubbish AA methods like FXAA and the like) From what I understood speaking with a game developer about this issue was: when you use a deferred renderer and want to have MSAA, you like have to work really hard to enable it (GTA V has it, as one of the few games out there). Given the fact that game one was bugged right from the start I find it kinda hard to believe that they went the extra mile to enable this, while most small developers just throw FXAA in and done. (BTW: game one doesnt even have FXAA... so I guess its just deferred lighting which is a completely different thing)

@FordGT90Concept
Thanks for pointing out that Wikipedia section! I had no idea support went that far back, although I suspect it still represents a rather small market share compared to all computing devices, that is probably a large subsection of gamers there.
My father, a software architect at a decently large company for the last fifteen years, has been teaching himself Vulkan recently. The number one concern he brought up with me: "I have to query for everything!" Although "Vulkan" as a system may exist in the card's drivers and enough of the hardware for it to function, on those older cards most of the Vulkan functions either won't exist, or will have software implementations. Either would be disastrous for performance, with one halting the game entirely and the other making it MUCH slower than OpenGl. I don't know what cards the frame-rate and CPU usage tests were run on, but I'll bet running the oldest compatible cards will see the opposite of those returns. (Except, perhaps, in the CPU usage drop -- that's likely to remain regardless of the graphics card used, as that depends on the drivers for the card which have been steadily improving.)
It's my personal opinion that Vulkan is a bad idea for this project; IDGI can make decisions as they like. I'm continuing to argue that side mostly because it's forcing me to do a lot of research, to re-examine my preconceptions and become a better CS student. Hence my trying to determine whether game one was deferred- or forward-rendering.

@fanatictentacle
-I may be misinformed, but MSAA works fine with deferred rendering as long as you draw lighting data for each sub-pixel in a fragment -- literally just calling a function N times instead of one, and saving N results. That way, when it picks the lighting data for the individual sample, it can pick at the MSAA super-sample scale rather than at the fragment scale -- getting rid of the lighting artefacts that initially led developers to think that MSAA didn't work in deferred environments. I personally think that's pretty easy to implement.
-I suspect that the IDGI team removed FXAA because it blurred all of the text and textures placed on objects around the world; wouldn't it suck to be unable to read the Pawn, Bishop, Rook, and Knight numbers on the shoulders of every uniform? I knew at first that I couldn't remember the names of every character, so those numbers were a godsend.
-Finally, what's the difference between deferred rendering and deferred lighting? I can't find anything, and it's left me very curious.

Kepler may not do so great because it is radically different from Maxwell and Pascal. But GCN (HD 7xxx thru RX 5xx), to this day, is fundamentally the same. Amateur benchmark (20-60% faster in Vulkan compared to OpenGL):https://www.youtube.com/watch?v=S5VerVlqCYI

Remember, Vulkan was based off of Mantle. AMD designed GCN with Mantle in mind.

getting rid of the lighting artefacts that initially led developers to think that MSAA didn't work in deferred environments

From what I cought hearing to my gamedev buddys this is exactly the thing. The first games with deferred rendering had this problem. Now it seems to get better.

As to deferred lighting: I can only tell whats left in my brain; but as I recall it my friends were referring to that as a method of getting more lightsources with shadows and everything to work in an older engine. In this instance the source engine. From the start it wasnt meant to handle more than 3 (or smething) lightsources. But with some extension you can get more than that. Sorry, I'm not a game dev myself, I just have friends who do it as hobby. So I could have gotten that one wrong