Author Topic: Graphics clarification: Unity and DirectX  (Read 9196 times)

Offline Cyborg

  • Master Member Mark III
  • *****
  • Posts: 1,957
Graphics clarification: Unity and DirectX
« on: February 11, 2017, 11:58:14 am »
I'm a little bit confused about the graphics pipeline and modding. I know you are using unity, and I know that Windows is up to DirectX 12, but maybe this doesn't use DirectX at all. Can we mod graphics effects?

For those of us preparing our machines for AI war, need some information. In the interest of creating the best space war possible.

I watch the development diary videos, and Chris gives reassurances that we could literally turn off everything and play the game with icons on a toaster. Well, okay, but then he goes on to show a battle with some explosions. There is also some lighting.  If someone were going to build a machine, what is needed?  Are we using any DirectX 12 effects?

Just even a simple specification on which technologies are in play,  can make sure we have the right parts.
Kahuna strategy guide:
http://www.arcengames.com/forums/index.php/topic,13369.0.html

Suggestions, bugs? Don't be lazy, give back:
http://www.arcengames.com/mantisbt/

Planetcracker. Believe it.

The stigma of hunger. http://wayw.re/Vi12BK

Offline keith.lamothe

  • Arcen Games Staff
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,505
Re: Graphics clarification: Unity and DirectX
« Reply #1 on: February 11, 2017, 12:06:01 pm »
I don't think anything in the game will require DirectX-anything. Unity uses it if it can, but it will fall back on OpenGL, etc if it has to. Generally we don't even have to think about what your graphics platform is, and you don't have to think about how we wrote our stuff; Unity just figures out some way to make it work. That said, alpha testing will be good for finding any exceptions to that so-convenient-sounding idea, while we still have time to deal with them.

As far as modding, yes, you can create new shots/effects/etc; basically the same way we do (i.e. involving unity, free version for the modders) though the workflow won't be identical because Blue and Chris have some paid-for tools we can't legally bundle in. So if you want a new shot type, or a new explosion that occurs when a specific shot type hits something or a specific entity type explodes, etc, that should be doable.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Cyborg

  • Master Member Mark III
  • *****
  • Posts: 1,957
Re: Graphics clarification: Unity and DirectX
« Reply #2 on: February 11, 2017, 07:15:05 pm »
As far as modding, yes, you can create new shots/effects/etc; basically the same way we do (i.e. involving unity, free version for the modders) though the workflow won't be identical because Blue and Chris have some paid-for tools we can't legally bundle in. So if you want a new shot type, or a new explosion that occurs when a specific shot type hits something or a specific entity type explodes, etc, that should be doable.

Amazing. Okay! Thanks.
Kahuna strategy guide:
http://www.arcengames.com/forums/index.php/topic,13369.0.html

Suggestions, bugs? Don't be lazy, give back:
http://www.arcengames.com/mantisbt/

Planetcracker. Believe it.

The stigma of hunger. http://wayw.re/Vi12BK

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Graphics clarification: Unity and DirectX
« Reply #3 on: February 12, 2017, 11:23:32 am »
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. :)
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Cyborg

  • Master Member Mark III
  • *****
  • Posts: 1,957
Re: Graphics clarification: Unity and DirectX
« Reply #4 on: February 12, 2017, 01:13:12 pm »
I signed up for the early alpha in kickstarter, so assuming the modding package is ready later this month, we can try it both ways and see what happens. AI war is about gigantic battles, after all, but if there is some cool effects that we can put on the GPU, I'm happy to do it, at least for single player.

Maybe multiplayer is something else.

Can we use stuff like these:
https://www.assetstore.unity3d.com/en/#!/content/3045
https://forum.unity3d.com/threads/pyroclastic-explosion-released-free.195611/
Kahuna strategy guide:
http://www.arcengames.com/forums/index.php/topic,13369.0.html

Suggestions, bugs? Don't be lazy, give back:
http://www.arcengames.com/mantisbt/

Planetcracker. Believe it.

The stigma of hunger. http://wayw.re/Vi12BK

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Graphics clarification: Unity and DirectX
« Reply #5 on: February 12, 2017, 05:47:08 pm »
Absolutely, you can do all sorts of cool stuff.  And yep, anything like what you linked would work -- though that would be a pretty big graphical downgrade with this particular two. ;)

You can mod in custom explosions for specific ships, or just as replacements in general.  You can use the shuriken system to make your own custom particle systems, if you want.  If you make LODs or not for it you can use it, so you can test it with an un-optimized form and see how it looks, then later add LODs only if it's worthwhile.

If you create something that looks awesome, and which is all your original work and/or public domain stuff, you can always mention it and we can see about inclusion in the main game.  eRaSer did some explosion sprites for the original game, for instance.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline eRe4s3r

  • Core Member Mark II
  • *****
  • Posts: 2,825
Re: Graphics clarification: Unity and DirectX
« Reply #6 on: February 12, 2017, 07:36:43 pm »
Is the sprite system more robust than in AI war 1? Rotation parameters, animation of parameters over life time, fade-out time, on-death events, potential collisions, spawning entire spawners that stay in position and are not attached to an object/ship (required tons of stuff like smoke and debris particles on hit...)?

And most importantly, can we add more light, GI (for nebula) or color mapping, exposure control? And how would we do that? Also can we specify distortion textures via shaders and not via the water system in Unity? (kinda important for realistic looking impact and explosion effects)... and stuff like that ;p Shurikan is pretty powerful, but it only ever looks cool if you emit custom shaded animated particles.

Ps.: I only plan to mod this game once it's released, and if I actually like it but not how it looks ^^
PPs.: Is there plans for dedicated Vulkan support? Because this would make a big difference, Vulcan has far superior instancing than anything you can do in D3d9
Proud member of the Initiative for Bigger Weapons EV. - Bringer of Additive Blended Doom - Vote for Lore, get free cookie

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Graphics clarification: Unity and DirectX
« Reply #7 on: February 13, 2017, 09:55:01 am »
I'm not sure what you mean by sprite system -- do you mean particle system?  We're using the full shuriken system, so you can do whatever you like in there.

Actually, technically even that is incorrect: we're spawning an object (with whatever sub-objects) at certain times, and then it does whatever you want and disappears after a while.  So if you had another particle system you wanted to use in there (popcorn fx, whatever), theoretically you could do that.  It's pretty darn flexible.

As far as shuriken itself goes, it has all of those various parameters and more.  A lot of those things can be adjusted by curves, etc.  It's just the built-in unity particle system, and it's extremely powerful.  I take no credit for it.  Yes you can add in lights and similar, although I don't recommend it.  Distortion effects are very possible through the particle system (I think you're confusing my use of the water shader in unity for vertex animation with a generalized screen-space distortion effect in particles, which are two very different things).  The distortion effects in unity tend to look awesome, but bear in mind that if you've got a ton of ships exploding at once, you're going to absolutely overload the GPU very fast, even on a high-end rig.  I don't think it will wind up being worth it in most cases.

In terms of adding various post-FX, that sort of thing is possible, sure.  It would take a little bit of coding, but you could basically just have whatever your post-FX monobebehaviour is in an external dll, then have that look for the various cameras the game uses and attach to them as needed. It might take an extra hook from us to say "attach any you have now, please" when the game is first starting up, but that would be easy enough.

The nebula backgrounds are on their own camera, and then the rest of the game stuff is on a separate camera, so you can adjust their post-FX separately somewhat (they are composited past a certain point, so it depends on when you are doing your fx in the call chain).

Some of the basic stuff like exposure adjustments you can handle directly through the Beautify component that we already have attached to the cameras, and there's actually quite a bit there that could be used if desired.  Those things would again require some simple coding (just to set values on them like exposure +1 or whatever), but it could be done with minimal fuss.

Dealing with GI is... a challenge.  It all has to be realtime, naturally, since there's no chance to bake a procedural scene like this.  We do have realtime emissions and so on, but we have light bounces set to 0.  Again with a small bit of code, you can override that on the scene.  I honestly don't think that would add much.  Some SSAO with a color bleed component would probably give you a better result, but even there the ships are low-poly enough that I don't know just how well that will work.  Typically my feeling is that there has to be a minimum geometry complexity there before those approaches work well, and there just isn't a poly budget for that on a per-ship basis in a game like this. 

Something like SEGI could potentially grow into a tool that would work here, but it's too unperformant right now for a scene this scale.  Unity doesn't have anything on its public roadmap that is truly revolutionary for realtime GI yet, unfortunately.  Maybe they'll surprise us this year or next year.

Dedicated Vulkan support is my preferred path, yes.  There is no instancing at all in DX9; that didn't come until IIRC DX10.  But unity doesn't directly support DX10, it just goes DX9, DX11, and then kinda-sorta DX12 (it's experimental).  Vulkan is in beta 5.6, and once that's out of beta (probably 1-2 months from now), that will be our preferred path.  Only exception is folks on OSX, which would have to use OpenGL 4.1 or Metal.  For folks on older GPUs that don't support Vulkan, the DX9 support (and by extension really talking about SM3 and so forth on the OpenGL side, too) would be the solution.  I don't want to leave folks absolutely behind on those card generations.

The current supported card generations: https://en.wikipedia.org/wiki/Vulkan_(API)#Compatibility

Fermi got left behind, despite originally being intended to have support.  Having a minimum of a Kepler-based card is not a dealbreaker by any stretch, since that's basically 5 years old now.

Intel chipset support on linux goes all the way back to ivy bridge (so that's equivalent timeframe), but on windows you have to go all the way up to a beta driver set for skylake (ow -- that's 2015).

Radeon has the same general timeframe (2012) on windows, but anything older than R9 is experimental on linux, which is a bummer to say the least.  That still gets those folks back to 2014 on linux, but that's not absolutely the best, really.

In terms of looking to the future: vulkan is absolutely it, in my opinion.  As the game evolves over the years hopefully, vulkan's baseline card support is going to be further and further in the rearview mirror.  But the legacy DX9 and OpenGL 4.1 support may always be a bit of a thorn in our side for basic support, simply because we don't want someone to be able to play the game one day, and then next release suddenly their computer isn't good enough.  It would be a lot cleaner on our end to just dump support for the legacy pipelines when 2019 or something rolls around, but I don't think that would go over well.

We may wind up HAVING to do that at some point as we upgrade to newer unity versions that change the system requirements around.  In that case we'd have a legacy build of the game for those affected who don't want to upgrade to within-5-or-6-years-old hardware.  Hopefully those wind up being a vanishingly small group of affected people, and hopefully unity doesn't put us in that position anytime soon.  But if history is anything to go by, that would eventually happen; the game either will be stuck on an older unity version and thus limit the majority of players from the latest in performance and goodies, or else we upgrade and the minimum system requirements inch upwards a bit, making some folks mad.

We'll just have to see how that is at the time, really, and what the overall desires of the fanbase are.  If things are running great enough, then maybe we just stick with whatever version of unity doesn't cause a min system specs shift.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Aklyon

  • Core Member
  • *****
  • Posts: 2,089
Re: Graphics clarification: Unity and DirectX
« Reply #8 on: February 13, 2017, 12:36:52 pm »
I'm not 100% sure I understood all of that, but it was interesting to read anyway, Chris.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Graphics clarification: Unity and DirectX
« Reply #9 on: February 13, 2017, 02:51:42 pm »
Yeah, definitely an acronym-fest, wasn't it?  I sure do love that area of the work, though, I have to say.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline z99-_

  • Full Member
  • ***
  • Posts: 112
Re: Graphics clarification: Unity and DirectX
« Reply #10 on: February 13, 2017, 04:03:05 pm »
Personally, I want to hear about Unity's garbage collector again :P

I like reading posts like these, they give me a reminder of how it might feel to others if I started going off about vector calculus or something. :D

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Graphics clarification: Unity and DirectX
« Reply #11 on: February 13, 2017, 04:27:49 pm »
Personally, I want to hear about Unity's garbage collector again :P

This guy sums it up super well: https://forum.unity3d.com/threads/mono-garbage-collection-can-i-get-a-summary.228199/#post-1519575

Quote
Unity is using what could be considered a "proof-of-concept" garbage collection algorithm that might be used in a project for an upper level CS course as it's very simple to integrate. Even the Mono docs from the time it was released stated that it was horrible and shouldn't be used in production systems.

It's only been about 12 years they've had to fix this...

Meanwhile, mono has done some amazing stuff: http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

Siiiiiigh.  Boy I wish we had that.

Granted, these days it doesn't matter much anymore, but yeah.

I like reading posts like these, they give me a reminder of how it might feel to others if I started going off about vector calculus or something. :)

Yep, I can only imagine, heh.  Some of the folks here could follow that, but definitely I would not be among them. :)
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Cinth

  • Core Member Mark II
  • *****
  • Posts: 2,527
  • Resident Zombie
Re: Graphics clarification: Unity and DirectX
« Reply #12 on: February 13, 2017, 05:13:09 pm »
Fermi got left behind, despite originally being intended to have support.  Having a minimum of a Kepler-based card is not a dealbreaker by any stretch, since that's basically 5 years old now.

Heh, you do know I'm running a 580, right? 
Quote from: keith.lamothe
Opened your save. My computer wept. Switched to the ST planet and ship icons filled my screen, so I zoomed out. Game told me that it _was_ totally zoomed out. You could seriously walk from one end of the inner grav well to the other without getting your feet cold.

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Graphics clarification: Unity and DirectX
« Reply #13 on: February 13, 2017, 05:50:41 pm »
Fermi got left behind, despite originally being intended to have support.  Having a minimum of a Kepler-based card is not a dealbreaker by any stretch, since that's basically 5 years old now.

Heh, you do know I'm running a 580, right?

Ooh, forgot that.  Well, that will be very helpful for having someone direct on staff to test that.  That way you can load it up in the unity editor and see what happens in the profiler for you.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Cinth

  • Core Member Mark II
  • *****
  • Posts: 2,527
  • Resident Zombie
Re: Graphics clarification: Unity and DirectX
« Reply #14 on: February 13, 2017, 06:37:40 pm »
Fermi got left behind, despite originally being intended to have support.  Having a minimum of a Kepler-based card is not a dealbreaker by any stretch, since that's basically 5 years old now.

Heh, you do know I'm running a 580, right?

Ooh, forgot that.  Well, that will be very helpful for having someone direct on staff to test that.  That way you can load it up in the unity editor and see what happens in the profiler for you.

Let's just hope it goes well.
Quote from: keith.lamothe
Opened your save. My computer wept. Switched to the ST planet and ship icons filled my screen, so I zoomed out. Game told me that it _was_ totally zoomed out. You could seriously walk from one end of the inner grav well to the other without getting your feet cold.

 

SMF spam blocked by CleanTalk