If I have understood your approach, instead of drawing let's say a grid on nxn quads, you are building a mesh from all that quads and trying to render it with a single draw call, right?

Storing sprite colors into vertex color attributes it's fine, and that's a rather common approach.

For what concern blending (and not considering gl_LastFragData), you can't specify a different blend mode without using an additional drawcall neither on plain OpenGL, am I wrong?

In other words, you should setup different blend modes using glBlend in between drawing indexed primitives(glDrawElements), if all vertices are store inside the same VBO or VAO. Am I wrong?

But Unity shaders are still a bit mysterious. The unity docs aren't getting through to me and I can't find any good tutorials on really how they work and what gets called in what order. I tried:

Even if blend options (and lot of other stuff such as stencil test, depth test,..) are stored inside unity .shader files, their aren't compiled into shader code. AFAIK are just "meta data", used by the engine to setup blend modes just before the drawcall with the real compiled shader(that under the hood is just Cg or GLSL).

I guess the minimum number of draw call correspond to the different blend mode you need to support.

If your mesh is static I guess the most performant solution is: when you generate it and set the indices you can specify the submesh index they belong to. At each submesh you can (maybe must), assign a different material (that can have a different shader accordingly to the required blend mode).

This way Unity's static batching will take care of drawing your mesh using a drawcall per material(assuming nothing else breaks the batching, such as multipass per pixel lights).

If your mesh isn't static, than you can consider using Graphics.DrawMesh with MaterialPropertyBlock in order to minimize state changes.

hope this helps

If I have understood your approach, instead of drawing let's say a grid on nxn quads, you are building a mesh from all that quads and trying to render it with a single draw call, right?

Storing sprite colors into vertex color attributes it's fine, and that's a rather common approach.

For what concern blending (and not considering gl_LastFragData), you can't specify a different blend mode without using an additional drawcall neither on plain OpenGL, am I wrong?

In other words, you should setup different blend modes using glBlend in between drawing indexed primitives(glDrawElements), if all vertices are store inside the same VBO or VAO. Am I wrong?

But Unity shaders are still a bit mysterious. The unity docs aren't getting through to me and I can't find any good tutorials on really how they work and what gets called in what order. I tried:

Even if blend options (and lot of other stuff such as stencil test, depth test,..) are stored inside unity .shader files, their aren't compiled into shader code. AFAIK are just "meta data", used by the engine to setup blend modes just before the drawcall with the real compiled shader(that under the hood is just Cg or GLSL).

I guess the minimum number of draw call correspond to the different blend mode you need to support.

When you generate it and set the indices you can specify the submesh index they belong to. At each submesh you can (maybe must), assign a different material (that can have a different shader accordingly to the required blend mode).

Assuming you are using a single pass shader, you can have one draw call for each material. If you have multiple static meshes with the same materials, then unity can batch them together.

If you have multiple dynamic meshes, than you can consider using Graphics.DrawMesh with MaterialPropertyBlock in order to minimize state changes. (More drawcall, but cheaper due to less GPU state changes)

hope this helps