You can have only 4 entity skins and 4 material skins available in a shader. Since your problem concerns only terrains, you could access the blendmap over a static bitmap (every BMAP* can be access in a shader, if the name is known, e.g.
BMAP* myBitmap; is accessible in a shader via
texture myBitmap_bmap;), so you could use 4 entity skins for the textures and 4 material skins for the normal maps. Since each texture has 4 channels, you have virtually (4+4)*4 = 32 channels, which would allow 6 RGB textures with their respective normal map in XY format (Z component can be restored). A special application is therefore needed to encode these 6 textures + 6 normal maps into a total of 8 RGBA images.
An alternative would be use -only- static bitmaps like
BMAP *terrainTexBase, *terrainTexBaseNm;
BMAP *terrainTex1, *terrainTex1Nm;
BMAP *terrainTex2, *terrainTex2Nm;
BMAP *terrainTex3, *terrainTex3Nm;
BMAP *terrainTex4, *terrainTex4Nm;
BMAP *terrainTex5, *terrainTex5Nm;
BMAP *terrainTex6, *terrainTex6Nm;
...
But this requires a manually loading of textures into those bitmaps.
To modify the terrain shader posted above to use 4 instead of 3 textures, while the channels are stored in base, red and green textures, you have to compose the blueColor by their alpha values:
float4 blueColor = float4(baseColor.a, redColor.a, greenColor.a, 0);
Exactly the same procedure for the normal.
Then you have to adjust the lerp's, so that you use ONLY the .rgb components of the colors and normals, so that you DON'T accidently mix something strange by using the alpha value of the colors which store a channel of the blue color / normal.
The lightmap is stored currently in the blue channel of the blendmap, you would then have to adjust it to the alpha channel then:
and, of course, use the blue channel value as weight for the color/normal of the blue texture.
