Category: Art Discussions

Goodbye, Alloy, But Thanks For Teaching Us A Lot

As of our upcoming version 0.610, we’re removing the Alloy Shader framework.

The above is a tutorial for Blue, our artist, though if any modders who are creating custom models are also using substance painter, this shows you how to set up your setup, too. You can also infer pretty easily how to do combinations manually using Photoshop channels to create packed maps, too.

Anyhow, we’re moving away from the Alloy Shader Framework to instead use custom shaders that give us an equivalent look with a vastly reduced workload and with definite compatibility with future unity versions, and this tutorial covers Blue’s side of what needs to change.

The above is a tutorial for Cinth, but this also is useful for any modders who are creating custom graphics for the game.

As noted in this video, this saves us a ton of manual work. A ton.

Also in this video I randomly stumbled across a visual improvement to the custom player ark Rorqual Hegira, so you can see how that evolved a bit thanks to the extra flexibility of this new shader set.

 

Some screenshots of newly-painted PBR ships.

These ships are painted by Blue using Substance painter — well, overpainted by Blue.  These were ships that she had previously painted in photoshop directly in a cel-shaded fashion, and which now she’s overpainting to give it a mixed realistic look.

It’s worth bearing in mind a couple of things:

  • These are screenshots from Substance Painter, so it will look a bit different in Unity.   See my recent videos on that subject.
  • These have emissive parts on them, but that REALLY doesn’t show up properly in the substance painter view, so you’ll have to imagine that part for now. ;)

Autocannon Minipod

Old:

First revisions:

My main note on that was that it didn’t feel beat-up enough, although beyond that I really love it.  And, um… what a difference, right??

Newest:

Aww yiss, now we’re talking.

Fighter

Old (although with some improvements that were overdue on the cel-shaded part):

New:

I just love the fighter, with how metal and beat-up it looks now.  It should do particularly well in the in-game lighting and with the lightmaps on. :)

Armor Ship

Old:

New:

I also really love the metalness here, and the added details.  I’ve asked about adding a variety of scorch marks on that, though.  We could do a variety of smart masks and then make them black with a very high roughness and potentially low metalness and that effect happens easily.

Bomber

Old:

New:

Overall I really like the bomber, although it feels a bit too gleamy-shiny in some ways.  Maybe having it a bit more worn of a metal as a base there is something we’ll do — or just introducing layers of wear.  I love the scratches we have going on.

Eyebot

Old:

New:

The eyebot is perfect, I love that glassy look it has and how perfect it seems in a lot of ways.  Really a different form of character to it, which is fantastic. :)

That’s all for now!

Just thought I’d share a bit of the progress that is being made.  Now I guess that our main problem is that these ships are drawn so bloody small in the battlefield — relative to the camera — that all that awesome detail is lost…

We’ll figure it out.  Someone on kickstarter was mentioning the same thing.  Maybe the answer is smaller squads of larger ships, or using more verticality to fit larger ships in the same radius, or who knows.  I don’t want to shrink the feeling of scale of the game, but at the same time we want to be able to see more than just the icon-fest, at least when zoomed in.

 

More AI War 2 art-related videos!

Figured I’d cross-post this new batch:

The above is a tutorial for Cinth on how to get things ready for Blue to do her painting in Substance Painter. It doesn’t handle the old-style of very-high LODs for us yet, but it gets all the rest of it.

The above is a video for Cinth on how we need to update our existing ship definitions to fit with our new “one material only” approach, which relies on mipmaps and GPU instancing for the bulk of its efficiency, rather than on baked vertex colors and dynamic batching.

The above takes a look at the newly-free alloy shader framework, which we’ve used in other projects, and looks at the difference in quality when we’re now integrating it into AI War 2.

Starting at 8:30 in there is a tutorial for Blue, and at about 23:00 in is a tutorial for Cinth.

https://assetstore.unity.com/packages/vfx/shaders/alloy-physical-shader-framework-11978

https://forum.unity.com/threads/alloy-physical-shader-framework-version-3-for-unity-5.305178/page-34#post-3278461

The above video is about three ships that I’d done with standard shaders previously, including the first backer’s custom Ark, and now they’re converted over to Alloy. Just a video of me working and chatting about it as I do. Why not.

“Rorqual Hegira” Ark Painting Videos

No actual painting takes place in the first video.  Instead we go through mesh simplification, examining the mesh, sizing things up, and generally getting things prepared so that we can just sit down and paint in the next video.

The second video shows the first of the 11 custom Arks that kickstarter backers commissioned for the game. This will be one of the Arks that anyone who plays the game gets to choose between.

This Ark, dubbed the “Rorqual Hegira”, was the vessel for the cetacean flight from Sol. I can’t say any of those words. ;)

Anyway, this goes through the process of actually doing the painting to make the cel-shaded baseline turn into a PBR (Physically Based Rendering) style. Basically what that means is taking something that looks intentionally cartoony and adding on a layer of processing that makes it react to light more like real materials do.

As part of that I also wind up adding various procedural details, naturally, as Substance Painter is really excellent for that sort of thing. All those little scratches and splotches and so forth that humans just aren’t meant to paint by hand with any speed or lack of repetition.

This video took way longer than I expected, mainly because my first idea for how to handle the metal body didn’t work out (I had feared from the start it might not, but it was a fun one to try), and because handling the “glass with something down inside it” is an inherently super-tricky request, and something I wanted to do justice to rather than just slapping an emissive glow on it and calling it good. I’m quite happy with how the result came out, although we’ll see what the backer thinks once he sees this video.

Enjoy!
Chris

AI War 2 gains IBL (Image Based Lighting)

Recently I showed how the graphics have evolved in the game via switching the materials to be more PBR-based (overpainting our cel-shaded visuals to augment them via Substance Painter).

At any rate, one of the things that was bothering me was the drop in quality between Substance Painter’s view of things and the view of things in Unity.  It still looked great in Unity, but was a notable step down.

So, I thought about that a bit, and made some changes to the lighting in Unity.  More on that in a bit — but first I should note that this isn’t something that is costing any extra performance hit on your GPU.  Yeah, you heard me — these sort of visual improvements can be “free” in terms of performance cost.  It’s all in the techniques, and I’ve been learning a lot on that front as I’ve been working on my “secret side project.”

Anyhow, that’s been paying big dividends for AI War 2 that I wouldn’t have anticipated.

Where We Started

That’s purely a cel-shaded approach modeled in Maya by Blue, and painted in Photoshop.  There’s a lot to love there, particularly in most of the ships in the game, but this was probably the number one ship that bothered me because the asteroid doesn’t look at all like rock.  (Then again — do rocks in any cel-shaded game look like rocks??)

At any rate, her painting and models were being fed into some custom shaders I created, and then tuned to have custom reflection maps and specularity and rim lighting, etc.

One of the big things that I struggled with with my shader was making the ships look really dramatic — but also visible — on their dark sides versus their light sides.

Often this really caused issues with the normal maps (those images that make things look more bumpy than the actual underlying geometry is) either being too harsh or too subtle depending on how close you were to the ship or which side of it you were on.

Next Up: Substance Painter

In a video you can see me painting that mesh using Blue’s cel-shading as a base.  The end result — in Substance Painter — is this:

Now, there are a few things to bear in mind.

First of all, this is using different shaders than Unity has.  Ones that don’t have to render in realtime, and certainly not thousands of objects in realtime — Substance Painter would choke and die on that.  But that tool is equally useful for offline cinematics or feature films as it is for realtime game usage.

That said, it should translate pretty well — shockingly well, to be honest — to Unity.  When you’re using full lightmapping and calculated ambient occlusion and so on, the visuals get very very close between the platforms.

Problem, though: you’re not able to bake lightmapping in unity for dynamic scenes.  At least… mostly not.  There are a variety of complicated techniques, and even some simple ones.  But let’s just say for our purposes here that isn’t feasible in this particular case. ;)

At any rate, the second issue is that this is using IBL, or Image Based Lighting.  And in Unity I was not.

What Is IBL?

Basically that means a 360-degree image cubemap is “shining” on the model from all around it.  Imagine having a painted translucent box and putting the model in it, then shining light evenly through every side of the box at once.  The result is an IBL look.

Actually, you know what?  Just check out this video with someone showing off what Unity can do.  Video is worth a thousand words… squared?

Okay, So What This Looked Like Coming Into Unity

This is a huge improvement over what was in Unity previously, but it’s still… not my favorite.  The lighting is very stark and harsh, and the specular reflections feel wrong, making me have to tone down the smoothness of the metallic shaders.  All that combines with the flatness of the lighting in general to make it feel… like a blander version of what I had before.

Well, heck — I’ve worked with IBL plenty of times before.  Let’s see what I can do.

Upgrade One

Starting with this:

We then move to this:

In order to get that second look, I turned off the main directional light in the scene, and am using just a single IBL light source.  I have to “bake” that in a really broad sense for Realtime GI to work in unity, but my understanding is that it isn’t really using anything other than the original cubemap since there’s no true baked data (no lighting probes, etc) in the scene.

At any rate, this is with the ambient light coming from the (invisible) skybox, which is an HDRI cubemap.  And then no other light sources other than the emissive materials on actual ships.  Oh, and the global reflection cubemap has also been toned down a bit and switched over to use a compressed version of the HDRI skybox rather than the studio lighting look I was using before.

This approach is pretty cool, and certainly more vibrant… but it’s still missing something.  It’s a very flat look to it, and if you circle the asteroid the lighting is even on all sides.  There’s no real shadows happening.

Upgrade Two

Now we’re talking!  This tones down the ambient light a bit, and then adds back in the directional light — but tones that down to about 60% of what it previously was, too.  I also made the directional light warmer rather than a harsh white, so that it would match with the HDRI image I chose.  Incidentally, I went through a variety of HDRI maps before finding one that felt right.

The overall settings used in Unity for this are as follows, if you’re curious:

And That’s Where We Are Now!

In a non-procedural game, there’s all sorts of fancy and highly-performant things that can be done with lightmaps and reflection probes and so on, but this is not that game. ;)

For performance reasons I’m not using parallax mapping/heightmapping/tessellation or baked AO on these models, either.  Those don’t contribute enough to the scene to be worth the added GPU and RAM costs, and we want this game to be able to remain as huge as possible.  All of the changes thus far have been either GPU/RAM-neutral, or come with a performance savings.

I may move back into slightly custom shaders for this, mainly so that I can handle the death effects for ships via parameters on the ship itself “eating the ship away” as it dies.  But in general, beyond that, this is how the game looks now (or will look, once we paint all these models again — blending what came before with what we can do now).

Hopefully this was an informative/interesting read.  :) It’s obviously something I’m passionate about, and I think it contributes a lot both to the mood of the game and our ability to sell it to a wider audience.

Chris

Updating the ship aesthetic in the game?

Chris here!  Wanted to run something by folks.

Hopefully you can click on that and get the fully zoomed-in full-quality version.  If not, here is a link to a version that will definitely be full size.

In case that (tiny, tiny) text at the bottom is hard to read, here’s what it says:

Note that this effect actually uses vastly less VRAM than the other approach — insanely — because we’re able to use compressed textures. The smooth, cel-shaded look shows imperfections in texture compression super fast, so we have to use higher-quality compression or even no compression. The PBR-based approach is inherently grungy and messy, which fits with the general vibe of a war-torn galaxy anyhow, and DXT5 compression doesn’t show any artifacts that aren’t just something your brain writes off as more grunge.

This overall aesthetic helps to make things look less “happy,” since that was a complaint withthe art before, but it also keeps the exact sameunderlying textures. However, we’ve overpainted those textures using procedural work in Substance Painter, giving a blend of hand-drawn and PBR styles that seems unique.

Thematically this seems more appropriate, and it’s also a lot (LOT) more efficient on your GPU, particularly if you’re on OSX or Linux (which can’t read BC7 compression. We’re talking a 4x to 10x reduction in VRAM, while getting added detail — just to be crystal clear. 4x on Windows, 10x on OSX and Linux.

We should also be able to make some of our LODs and asset-integration work a bit more efficient using this, too.

Any complaints?

Oh, Also — About The GUI

We’re having a lot of discussion about the GUI, and I’ve made a pair of videos on the topic.  Cyborg has been a huge help in focusing our attention in a positive way in this particular area.

Also, when it comes to the vibrance of the space backgrounds I’ve toned those down as of today, too — with the next build that comes out, 0.601, those will be much more muted.

And About Those Remaining Keys…

Still waiting on those from Valve.  So sorry about that!  I assume I’ll have the keys from Valve either this afternoon (PST) or tomorrow afternoon.  Otherwise I’ll get up with my contact there.

Cheers!

Chris

AI War 2 – Quick Look At Ship Designs (less than half).

Chris here. Since we’re now moving into starting the custom Ark backer rewards work, it was suggested that we show the existing ship designs to players. This videoonly shows the ones that are currently “wired up AND uploaded,” which doesn’t include remotely everything that is complete just yet, but it’s a good start.

More info is available in the forums.

Tutorial – Creating Nebula Backgrounds for AI War 2

A how-to guide for modders or other players who want to create nebula backgrounds for either their own use, or to send in for official inclusion in the game. This requires version 0.302 or greater of the game.

Taking a look at some AI War 2 ships during late alpha.

Chris here! This is just a video looking at a variety of the ships in AI War 2, or at least the graphics for them. These are in the version 0.124, which will come out early next week. It’s presently late alpha for the game (in the pre-Early-Access sense), and so these are coming up to a much more polished status now.

As part of our testing thus far, one thing that we’ve discovered is the need to use GPU Instancing. That was something that I hadn’t been sure if we’d need or not, and I’ve mentioned it since our first kickstarter for the game. I wanted to try to get away with dynamic batching, which is compatible with OpenGL 3.x and DirectX 9 and DirectX 10. However, the performance just wasn’t good enough, even in battles with only something like 5000 ships versus maybe 2000.

A few passing bugs aside, the performance was still better than AI War Classic with that scale of battle on the simulation side in particular, but GPU instancing became a clear need. So now the game is going to use that, which requires DirectX 11 or OpenGL 4.1, and basically hardware from 2010 or 2011, depending on your exact hardware and OS.

Realistically you needed hardware from that era at the oldest anyway in order to handle the CPU processing, so this really should be a moot point, but it was a bridge I hadn’t wanted to cross unless it really became clear it was needed. Well — now it’s clear. :)

A bug in the GUI sidebar aside, I was getting about 30fps in the aforementioned battle using dynamic batching. This is on a latest-gen i7 with a GTX 1070. Now with most of the stuff working with GPU Instancing, I get around 80 fps. There are still thousands of wasted draw calls because of some of how I’m handling my custom sprite system at the moment, and I expect to get my machine running that same scene at 120 or 140 fps by sometime next week. Knock on wood. :) But it definitely seems like that will be what happens on my rig, based on all my tests thus far.

Anyway, so we get to the question of how big battles will be able to be, and to that I still have the answer: I really don’t know. For a variety of reasons, we can do larger battles than AI War Classic if you’re running them on modern machines. On a machine past a certain age (maybe from 2012 or before?), then the battles of Classic might be larger in terms of what your machine can handle. I’m not sure. The newer your machine gets, though, and that’s looking to the future as well, AI War 2 starts pulling further and further ahead. This switching to GPU Instancing is a huge amount of future-proofing in and of itself.

Overall we just have a ton of performance optimizations and multithreading in the game already, and it’s built around a variety of design concepts that lend themselves to larger battles than the original. We still do hit the occasional hiccup, like the sidebar thing, though, which makes performance absolutely grind to a halt for a bit. That’s one reason why we do the alpha, though; so we can fix things like that, and they never last long. :)

All in all, we’re looking good! I’m excited about the recent changes, even if I am apprehensive about any potential backlash by someone angry about the system requirements change.

Thanks for watching!

Chris

Blue’s work on the new Lightning Corvette.

This is something I’m really jazzed to show you — it’s basically the replacement for the Electric Shuttle from the first game, except a bit revamped in a good way.

You may recall that Blue has been working on icons lately?  She actually finished those up yesterday, and the ball has been in my court since then.  She’s moved on to working on other things, including the Eyebots (not yet painted, but modeled) and then what you see above.

There are a variety of higher-priority ships than these that Keith put on his list, but I’ve been sampling from a few areas simply to get us a few more small ships earlier than later in the art process.  Those are a nice break for Blue compared to doing all the really giant ships first.  Variety being the spice of life, and all that.

No release today, but there should be one tomorrow, I expect.  Lots of things have been inwork, it’s just one of those times where it doesn’t fit to do a release on a given day.

Cheers!

Tutorial – Mesh Importing And Setup From Maya

March 7th, 2017 – Quick notes for Cinth (or modders!) on importing models and then getting them properly combined and atlased. Unfortunately if you want to use the same tools that we are for the atlasing and the combining, you’ll have to purchase licenses for those for yourself. But there are tools in Blender and other locations that do similar things for free.

The tools shown in use in this video were:
Mesh Simplify
Pro Draw Call Optimizer

Fuel Generator Model (WIP) Becomes Reactor Model

Remarking on the last WIP for this, forumite MHB noted that it looked more battery/electrical-like than fuel-styled.  I kind of brushed that off with “yeah, you’re right, but wait until you see it with paint, since that tends to change things a lot.”

Well, paint is in progress (still WIP), and it looks even more electrical now. ;)

We often have “happy little accidents” (in the best Bob Ross sense), when it comes to art, design, coding, and so on.  This is actually a much cooler Reactor design than I’d initially envisioned, and when I brought this up with Blue she thought it would be a great thing to switch over, and she could work on more detailing to make it look even more electric.

Happy little accidents — one of my favorite things. :)

Thanks, MHB!  I’m not sure I would have called that appropriately had you not said something.

Fuel Generator Model (WIP)

Blue’s current work, with the model completed for the fuel generators, but no textures on them yet:

Blue’s WIP tachyon arrays.

Figured I’d share these shots she took of her work in Maya:

I’m really excited about how this is coming along, too! :D

Cinth plays around with wormhole graphics.

He’s been doing some pretty slick stuff. :)

And then…

Granted, visibility would be too low with this to really use it in the game, I think.  But it’s the start of something really neat. :)