Grah, our forums didn't even email me about this topic! Frustrating when that happens. Various answers, though:
1. There actually aren't any true lighting effects in use here. We're using one directional light, and some of the shaders I've coded ignore that or bend it to always come from a certain direction or do other really funky things. There are absolutely no point lights however, and so from a lighting standpoint this is all bog-standard DirectX9.
2. Actually everything I've shown thus far has been 100% in DirectX9, most of it shader model 2.0, some of it shader model 3.0. But this easily runs in OpenGL in the same equivalence.
3. For performance purposes, we're not even running shadows here at all. Most of the lighting is handled in a Blinn-phong fashion rather than PBR, and any sort of "shadows" you see are actually light calculations in an environment with one directional light, no shadow casters, no self-shadows, and a whole lot of special effects that are nonetheless very old-school-capable.
4. All of the fancy lighting is pretty much based on emission maps and then post-processing bloom effects, OR it's stuff that is programmatically calculated on the GPU in a procedural fashion (notably the planets, which are awesome code by FORGE3D, not me).
5. We are not using AO maps, heightmaps, tessellation, or anything of that sort, nor do I plan to. Some of the things that look like they might (the wormholes) are actually just a simplistic GPU-side vertex animation. Much more old-school than tessellation, and it's actually IIRC just the old unity4 water shader being put to unusual use. At some point I'll likely re-code that or else just go with a completely different effect, though. I'm still not really happy with those effects, I have to confess.
6. We're not even using HDR at the moment! Unity doesn't support that in concert with MSAA, and for visual quality reasons it's important for us to use MSAA rather than something CPU-side like temporal antialiasing. We don't have the CPU cycles to spare for that, and we don't need any of the other deferred-rendering peipline stuff (better handling of many lights, for instance, since we have only one light), so we're in simple Forward rendering. Unity 5.6 adds HDR support for Forward+MSAA cameras, so I will happily be turning that on there; but I've been able to handle a lot of HDR-like effects even without that support, as you can see in the videos.
7. The main thing that DX11 adds that I would want is GPU Instancing (drawing many copies of a mesh), but we're working around that by instead relying on dynamic batching in unity and then my own custom LODs system. That is definitely less efficient, but it's the only thing that will run on all OSes and the majority of hardware. So if it can't work except with DX11, I don't consider it a viable thing for this game, basically.
8. With unity 5.6, all of that changes, though. Vulkan support alone is apparently yielding around a 60% gain in performance for a lot of games, although I've not tested it in AI War yet since that's still in beta (should be out before we hit EA, though). My goal is to start using Vulkan and Metal for GPU instancing, and in general just their performance characteristics. Though I've heard some shaky things about Metal performance-wise. I'm unsure if we can completely leave behind DX9 and OpenGL 4.1, but it sure would be nice. We could almost completely remove any reliance on dynamic batching in that case, for instance, which would offload yet more work from the CPU to the GPU.
9. Visually I wouldn't be planning on doing anything new with Vulkan or Metal that I can't already do, I want to be clear. It's purely a matter of performance and GPU instancing. My goals there are simply to keep the GPU pipeline from ever being idle, and to offload as much from the CPU as possible.
10. The explosions that you're seeing there are using either pure shuriken particles, or particle spritesheets in shuriken. It's a mix between them. They have LODs as well, and some of those explosions are actually as few as three particles when viewed from a far distance. Most are about 12 particles at most when viewed up close, for that matter. Maybe 20 in a couple of cases. Despite appearances, none of those explosions use any lighting effects whatsoever, and their shaders are some of the simplest in the game; though of course they are having to use the transparency buffer, which cranks up their expense some. But still, shuriken is pretty efficient about those things.
11. I'll be making the shaders that I've coded or have rights to open-source part of the modder package, and folks can then just use those to keep the visual look consistent. But if someone wants to go ahead and create something that requires, say, sm5.0, then there's nothing stopping them. That would run on everything except DX9 that I've discussed, and unity has a wonderful fallback shader system -- so in the event of any shaders like that, defining shaders that are at most sm4.0 that are the fallback is great. I have different shaders that are used for each level of the LOD (well, the latter two, anyway), incidentally. They get simpler and simpler at higher LODs, and it's just stuff I cooked up in Shader Forge. Those can be edited by hand if you're into HLSL(ish -- it's unity's custom version), or if you have shader forge you can open it in that.
12. In a very generalized sense, I don't presently have any idea what the minimum system requirements are for an acceptable flashy-fun experience. I know that at the absolute bottom level if you just want to play the game, you pretty much need a DX9 or OpenGL 4.1 card, which is most anything from 2008 on. But I also know that likely if you have only a single CPU core, you're probably going to have a pretty bad time, so realistically most people who try to play it will probably have a computer circa 2011 onwards, roughly speaking. How it will run in all those cases I don't yet know. The bottom and the top are easy to predict, but the lower-middle gets kinda fuzzy.
13. One example of that is with the rim lighting. I'm not sure how much that will really affect GPUs that are on CPUs that can run the game well. The rim lighting is all a simple effect calculated in the shader itself, and has nothing to do with actual lighting in a traditional sense. This isn't light bleed from the main light source, but rather is using a simple fresnel calculation (aka dot product from surface normal and view direction); it's not calculating the angle of the light at all. However, the reason it looks a bit like it is is that I've got a secondary bit in there that uses the light attenuation calculation to reduce the fresnel result on shadowed sides of the ships. Just how expensive is all of that on the GPU? I honestly can't tell. I have yet to run into a circumstance where that was the bottleneck instead of the GPU pipeline itself. When we run into a situation like that in the alpha group where the GPU pipeline is fully utilized and not the problem, but the GPU itself is struggling (this probably is not even possible until Vulkan is on), then I can make some options for swapping out the shaders with ones that don't have the light attenuation effect in there, or which don't use the fresnel effect at all, and we'll see what happens. Only LOD0 and LOD1 of models use that shader anyhow, and there tend to be pretty few ships on screen at once that are at that high of LOD at a time. Once you move to LOD2 we actually start using texture-less shaders that have the textures baked into the vertex colors. LOD2 has a version that does some clever (if I do say so) math in order to create a fake emission map from the vertex colors, and then LOD3 is just about as basic of an unlit vertex-colors shader as you can get, by design.
14. I guess one other thing that makes me excited about Vulkan and similar is better support for BC7. Right now I think it's actually loading those and flipping them over to DXT5, which uses far more VRAM than I'd prefer. That's on DX9, because I think DX9 doesn't handle BC7 and thus automatically and silently falls back to DXT5. Unity is pretty awesome like that. But with Vulkan, we should be seeing BC7 instead, which means texture pipeline usage that is something like 1/5th what it otherwise would be. This would be another argument in favor of DX11 as a supported platform, but I'm not sure that there's anyone who can run DX11 that can't run Vulkan, and the latter is preferable in every case I'm aware of. If we have to allow DX11 support for some group of people, I'm certainly not above it, though. That will be something we find out during the alpha, I'm sure. But in general I like some good old DX9 when we're not going nuts with the PBR.
15. Though, fun fact: Release Raptor, with all its deferred shading and crazy lighting and HDR and so on was still running DX9 and OpenGL 4.1. I had no reason for tessellation, and the GPU instancing was a lot less mature then and wouldn't have been all that helpful to Raptor (contrary to this game), anyway.
I'm happy to field other questions.
