Unity 5.5.0b3 (edit: 5.4.0p4) looks like a winner so far for AI War II.

[x4000]

Just figured that I'd mention that this currently seems like the version of unity we will go with.  I had been planning on at minimum doing unity 5.4 (Raptor was on 5.3.5p7, as 5.4 was still in beta at the time).  But the advantages in 5.5 seem pretty nice thus far (some of the GPU instancing stuff, and the better line renderers and the better compiler), without a bunch of bugs that I can see thus far (5.4 was frequently pretty rough during the beta).

This talks about some of the benefits to the particle system in particular, which always makes me happy: https://blogs.unity3d.com/2016/08/30/get-the-unity-5-5-beta-now/

A lot of the core features that I'm excited about were already in unity 5.4, but the difference in performance is a noticeable thing between 5.3.5p7 and 5.5b3 for my current test project.  I went from 500fps in one case (rendering a highly-detailed sun close up) to over 2000fps.  This is on a GTX980M, vsync off (really vsync is like the worst thing ever, I hate it.  Gsync or go home, heh -- I hope that becomes the standard, anyway).

Oh, and with MSAA on, since I'm using Forward mode (unlike Raptor I don't need a million lights and thus deferred shading).  That oddly makes HDR impossible for some reason, which I'll have to look at, but I can still use Linear instead of Gamma, which is for the most part good enough for me for now at least.

This is the first version of Unity I've ever used in any sort of real-world context with the secondary-thread render batching processing, and holy smokes I am in love already.  I am also amazed that finally they fixed the DX11 renderer for the editor itself; it was always fine in games for me, but on multiple computers and multiple sets of drivers the DX11 view of the editor itself was a bit bonkers for me.  Strangely the DX9 view actually was super blurry on text in 5.5b3 for me, but hopefully that's just an editor thing, sigh.

At any rate, I'm quite pleased.  DX11 equates mostly to OpenGL Core 4.1 IIRC, so this doesn't harm Mac or OSX compatibility -- just in case anyone was worried.  I'll probably target builds at DX9 and equivalent unless I have a reason not to, anyway, though.

Today has been a lot less work on the design doc, and more stuff like this as well as a variety of interesting design discussions in the Ideas subforum here.  I just needed a break from all those miles and miles of ship definitions, whew.  And not having anything visual to show you yet has been stressing me out, so I wanted to get to that sooner than later, too.

[TechSY730]

Does it also come with a version of Mono that doesn't have a "herp-derp" garbage collector?

(Ok, I am being a bit unfair there. AI War classic tickled the "worst cases" of its Mono's GC algorithm (any GC algorithm will have "worst cases", its unavoidable), in most other games it wasn't anywhere near that bad. The big problem was is that it reacted to those "worst cases" by crashing )

[chemical_art]

Glad to hear there is good progress on this front. Sometimes what is the best order to do tasks from a design standpoint is not the same as to do tasks in that order that is comforting to a human. Neither is absolutely anything 

[x4000]

Does it also come with a version of Mono that doesn't have a "herp-derp" garbage collector?

The GC is most definitely "herp derp" in every sense of the word.  I can't believe that they still have that stupid thing.

I don't know this person, but his quote amuses me and seems accurate from what I can tell:

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.

  http://forum.unity3d.com/threads/mono-garbage-collection-can-i-get-a-summary.228199/#post-1519575

It would explain a lot, frankly.

The biggest difference in the hitching will be how much transient RAM we throw off, and how we avoid doing that.  The new Unity GUI no longer does "herp derp" GC allocations, so that's a big plus right there.  Makes the GC hit a lot less frequent at the very least.

Glad to hear there is good progress on this front. Sometimes what is the best order to do tasks from a design standpoint is not the same as to do tasks in that order that is comforting to a human. Neither is absolutely anything 

Thanks.   My preferred work approach is typically:

1. Tackle the thing that I dread most.
2. Get burned out of that and then "slack off" by working on a bunch of smaller and easier tasks that still need doing.
3. Get progressively more stressed out by the feeling of slacking off, and the next big thing that is looming.  Also get sick of a lot of small things.
4. Finally snap and do the next big thing in a flurry of inspiration, then move back to #2.

It's a way of kind of tricking myself into a constant high output of whatever sort, which is somewhat my "secret" (when people ask how I do things so fast).  But it also makes it so that I am hopping all over the place from topic to topic a lot of the time, in order to do #2 and #3.  Moving to the unit definitions was a version of #2 for me, to avoid working on background factions, which were a #1 at the time.  Now the unit definitions became a hybrid #1 and #3, and the art is my new #4 and #2 combo.  All the various brainstorming and useful forum conversations, and the small writeups resulting from that, are my other version of #2 in parallel with that.

I'm an odd guy.

[x4000]

Looking like 5.4.0p4 may actually be what we go with instead.  They changed a few things in the shader includes for unity that are causing some issues with a variety of components, including shader forge.  That's not the end of the world, but that's my preferred way of creating my own shaders of any complexity.

There's also some sort of bug where the text is blurry as heck in DX9 mode, but the whole editor lags a lot after a while in DX11 and still has the issues I've had with DX11 in the editor on multiple machines forever.  I can always give OpenGL Core 4.1 a go, but at the moment I think that the trail renderers and few particle improvements are not worth the shift to their beta branch.  I am also excited about the increased number of shader keywords (256 now!), but that's not really relevant for this project.

Anyhow, I'm presently working on a tech demo of sorts that will not only do the needed profiling of people's machines (as described in another thread), but also will be something I can capture video in for the kickstarter, and either do a webgl or download-based build for people to play if they just want to faff about with a tech demo during the kickstarter.

Meanwhile Keith is working on the actual game, but he's focused on the internals and so the things you can actually see are ugly and tempy.  Past a certain point we'll combine my stuff into his project, and then we've got the first alpha build for backers.  In the meantime I can do nice prototypes of various things including the GUI and solar map and whatnot that are vaguely interactive, but not hooked up to an actual game in any way.  Helps for performance and usability testing, and rapidity of iteration on that, which is nice.

[Draco18s]

Looking like 5.4.0p4 may actually be what we go with instead.  They changed a few things in the shader includes for unity that are causing some issues with a variety of components, including shader forge.  That's not the end of the world, but that's my preferred way of creating my own shaders of any complexity.

I love Shader Forge.

[x4000]

Me too.  Shader Sandwich and a couple of others are also pretty good, but SF is the best.  SS is really good at helping you set up certain PBR things and rim lights and other particularly complex settings, but it can also be frustrating to set up the settings for.

[Draco18s]

Haven't used those others.  Had my last job purchase shader forge when it was on sale for like half-off.

Ironically one of the only shaders I've actually written I've had to do by hand.  Shader Forge doesn't do stencil masking.

[x4000]

Shader Forge doesn't do stencil masking.

Depending on what you're trying to do exactly, it now does.  They added the ability to do a variety of stencil buffer operations.

[Draco18s]

Shader Forge doesn't do stencil masking.

Depending on what you're trying to do exactly, it now does.  They added the ability to do a variety of stencil buffer operations.

In which case, in the last version I used.... heh.

Here's one thing I did by hand: https://s21.postimg.io/lrzm1h21j/finally.png
The only way to make it "better" would be to use a more complex way of calculating the extruded geometry (this just does a dirt cheap "every edge becomes a quad, trying to face the camera" and then stencils masks the original object--and in this case, doesn't draw it at all), which is doable and would fix the "rough edges" it has when using extreme thickness values: https://s17.postimg.io/rwdam5g2n/blow_out.png

That shader is freely available because there's literally no other free solution that is nearly as good (most involve "scale the whole object" which looks crappy on non-convex objects).

[x4000]

Nice work!

That is impressive indeed, and there are some various tools on the unity asset store that go for this but are pretty crappy.  Why are you using the Transparent path for it, though, I'm curious?  That's a really smart approach, anyhow.

I imagine that has a per-visible-face cost to use?

If you're not stenciling out the main object, how does that wind up looking?  I imagine that this shows on top of it, or is the z-depth of each vertex maintained? (Assuming you had z depth testing on in pass 2, which I didn't check).

This could be useful.

[Draco18s]

Nice work!

That is impressive indeed, and there are some various tools on the unity asset store that go for this but are pretty crappy.  Why are you using the Transparent path for it, though, I'm curious?  That's a really smart approach, anyhow.

The object itself was set to not-render just to show off what the shader did.

I imagine that has a per-visible-face cost to use?

I imagine that this shows on top of it, or is the z-depth of each vertex maintained? (Assuming you had z depth testing on in pass 2, which I didn't check).

On both of these: hell if I know

I only use it for "you are looking at a thing" highlight indication, so its not like I'm going to have a bunch that I need to worry about the cost for.

If you're not stenciling out the main object, how does that wind up looking?

I don't have a screenshot handy. Both of those were pulled from the comments on the answer.  And having computer issues I don't have access to stuff to create a new one at the moment.

[x4000]

Gotcha -- I was just curious.  No reason to do a ton of digging.

For a mouseover effect it is likely to be plenty efficient for any meaningful use cases.  I was thinking more of other cases such as unit borders, etc.  But I need to handle that a different way in general, honestly.

[Draco18s]

Yeah, probably not so good for unit borders.  Stencil masks do take two render passes minimum (and have limitations on how you're doing lighting--I forget which one, but I think it's deferred rendering that ends up using up anywhere from 3 to 6 bits of the stencil mask).

In terms of what it's actually doing to the geometry, AFAIK it's not that heavy. Unity can handle 100,000 vert meshes just fine (and in fact, the overhead on "two meshes" vs. "one mesh" actually says that "one mesh twice the size" renders faster).  It's just that it can't cache the results, so the standard "RAM vs. CPU" ends up heavy on the CPU side of things.  On top of that, if you're doing a 2D topdown view (or any fixed view point) you're better off supplying a separate, per-object* mesh because it's pre-computed.

*For some definition of "per-object" not necessarily per-GameObject, but rather that there'd be a common "this is a bomber outline" mesh squirreled away somewhere.

[x4000]

For unit borderes, I'd forgo the stencil buffer part.  I'm trying to avoid deferred shading if I can anyway -- I didn't know about the stencil buffer limitation there, but it must be that one rather than forward; I imagine that it's the g-buffer using those bits, if I had to guess off the top of my head.

Regarding having precomputed borders, that's all well and good assuming no scaling, but if you're scaling the size of the object and what the borders to sale up and down at a different rate, you want to do that realtime or else do some other method (dual gameobject there could work fine).

And yep I know about the really huge meshes, so long as you aren't doing things like bone-based animation with them (shudders).  The default is for its static batching to break things into 64k vert batches (the max unity can handle per draw call), and it can handle a number of those.  I know it can handle larger-vert meshes, but it must split them or something, I'm not sure.