Fixes blending issues while respecting #1704

[lukaspj]

The corrections to the blendTotal were reverted due to issue #1704 . This will revert that revert, while also making the terrain render in a single pass (at least for up to ~20 textures layers per terrain cell, which should be reasonable).

In order to allow rendering the terrain in a single pass, I had to move some calculations from vertex to pixel shader, so a benchmark on how this affects performance should definetly be considered.

In theory, it should be possible to solve this issue with the multi-pass rendering technique utilized currently, but I haven't been able to make it work.

Edit: Furthermore, due to an issue where you can't get the constNum of a texture, the code is a bit ugly and difficult to maintain, as it assumes a specific ordering in the shader's texture constants. Should only be an issue when someone messes with that part of the terrain shader though.

Edit2: Clarified it is 20 texture layers and not 20 textures.

[Areloch]

Sorry it took a bit to get this tested properly.

Looks like something's going oddball in the math with this. Using the stock textures, the blend breaks down when you get several materials in a small area(i've got 6 in a relatively small area on the terrain)

Screens:
(http://ghc-games.com/public/nuBlending01.png)
(http://ghc-games.com/public/nuBlending02.png)
(http://ghc-games.com/public/nuBlending03.png)
(http://ghc-games.com/public/nuBlending04.png)
(http://ghc-games.com/public/nuBlending05.png)

So we're getting a total burn out on the grass texture(detail goes full black, though the base texture is fine), which is also the first material, if that matters. The others look like they have their seams become jagged instead of smooth, we see hard seaming between blocks, and the detail textures look to be wrongly assigned(likely related to the first point. If our detail textures are being mis-indexed, it's possible that our first materials' detail texture is being pointed to an invalid point and doing black).

[Areloch]

Double checked. Behavior persists in Release as well. Tried the GL side. Fatal crash in debug, no actual error message though, just crashes in the GFXGLShader initHandles(). Looks like line 662, where it loops through the ConstantDescriptions. In GL Release, the blocks stop rendering as you get close to them, as if some sort of bizzare inverse LOD was happening.

[lukaspj]

I believe az mentioned that it'd be possible to get the constNum of textures soon? Maybe we should wait till that is possible and change the code so it doesn't rely on a specific order of textures.

I will try and see if I can figure out what goes on with openGL.

Sent from my OnePlus ONEPLUS A3003 using FastHub

[Areloch]

Ah, yeah, I remember you bringing up the constNum bit before. We'll definitely want to get that pinned down.