So, grondag is working on the static rendering PR, and it's very close to completion. EXCEPT

We are insisting on adding a feature called "multi-texture" - in essence, allowing to draw one quad with multiple texture layers. This has some advantages:

• for planned support of terrain materials with custom shaders, it allows passing additional data to the shader via textures,
• lighting calculations can be done once for said quad, saving some time in AO calculation,
• custom rendering plugins can further optimize the rendering of such quads (the default one just falls back to splitting the quads, as the vanilla pipeline cannot optimize this),
• future plans involving batched block entity rendering could benefit from the feature.

However, we're split on the bounds of multi-texture. As in, we want there to be a renderer plugin-definable maximum, but we're not sure on the minimum amount of layers a plugin should support.

• One option is for the minimum to be "one". Unfortunately, that means mods are discouraged from using the feature, having to write two codepaths.
• The other option is to set a minimum which covers most usecases. For example, "four", or "three". This makes plugins a bit more complex, but means mods can safely benefit from the feature.

Personally, I'm more fond of the option of "one", but fear modders not adopting the feature if so, not wanting to write two codepaths (though the difference should be fairly small, and the performance implications should only matter at scale). As such, it might be better to set an arbitrary "minimum", even if some plugins resort to just splitting quads to get there.

What do you think?

Is it possible to have an empty or blank layer? If so, having a minimum shouldn't matter much.

Yes. The minimum concerns strictly rendering plugins; that is "should a rendering plugin be forced to handle multi-texture quads, and if yes, what's the minimum that should be expected of one?"

I think three + lightmap might be a good number for plugins to expect to have to deal with, base + dynamic tex (like the I/O ports on a machine) + fancy effect + lightmap should be enough for most fancy uses.

I have some experience with writing shader and honestly, I would like to have more than only three. It's true that if you know what you are doing you can put a lot more information in a texture than you should by using different channels, but doing so would break compatibility with most of the available tools.
For me the minimum would be 1 base texture, 1 bump/normal texture, 1 specular, 1 more to fake AO or SSS and a last one for fancy dynamic stuff.
In total this would result in 5 + 1 lightmap.

Another question: How would this system handle 3d textures?

I have some experience with writing shader and honestly, I would like to have more than only three.

Nonono. The discussion is about the minimum. That is, how many should a rendering plugin support as the minimum? Keep in mind that Indigo is meant to be the minimal case; for extensive shaders you'd probably be using a more advanced rendering plugin anyway.

Essentially: "the minimum" means whether a compliant rendering plugin should be required to support, say, at least three layers (but could support more!), or at least four, or just at least one.

I have some experience with writing shader and honestly, I would like to have more than only three. It's true that if you know what you are doing you can put a lot more information in a texture than you should by using different channels, but doing so would break compatibility with most of the available tools.
For me the minimum would be 1 base texture, 1 bump/normal texture, 1 specular, 1 more to fake AO or SSS and a last one for fancy dynamic stuff.
In total this would result in 5 + 1 lightmap.

As @asiekierka noted below, we are looking for a minimum. A high-end renderer can do as many as it wants, though as you know there are some practical (esp. memory) constraints to usage of big vertex formats in a game like Minecraft.

Another question: How would this system handle 3d textures?

I've thought about it only a little so far. It's not the system so much as Minecraft itself and how terrain rendering works. Being limited to GL2.1 GLSL 120 also works against this for now. Open to ideas if you have specific use cases in mind. Would be something we tackle in the shader extensions.

Decided already