Hey guys,
I tried the new material that @Sploreg commited some days ago and I get peculiar results. If I use my standard 12 texture splatting shader (which I just took from the old material version and added further blending) my terrain comes out as always.
But because I wanted to switch to the “official” material version, I get the following output:
http://i53.tinypic.com/2zi7tq9.png
I filled all 12 sampler values, all three alpha maps, all scale floats and also have a normalized directional light in my scene. Is it just me?
Thx and cheers!
Oh btw, niftygui 1.3 is out. Maybe someone of the core team can update the lib 
EDIT: It is, however, viewpoint dependent. If I look along the positive x-z-coordinates I see no artifacts. And the more I rotate towards the negative x-z-coordinates (so I gradually turn around) it becomes more apparent. The error still persists if I disable all post processor effects.
http://i55.tinypic.com/28i23y0.png
Have you generated tangents on your terrain? Not having them will cause the black spots.
I don’t see how the changes to the new material can cause it… I could be wrong though. I have tried it with all 12 textures and it was happy. I will look at it today.
wait, never mind. I haven’t had caffeine yet
TerrainQuad should generate tangents automatically for you.
Can you post a test case?
A thought just came to me (due to more caffeine), you will need to set:
material.setBoolean(“WardIso”, true);
I just tested 12 diffuse textures and it is happy, I also tested a normal map on each one and it is happy as well. So if the wardIso change doesn’t work, there there is some videocard compatibility issue going on.
Hey Sploreg,
yes! Thx a lot! I was just trying to assemble a test case and you beat me to it (in some sense) 
Enabling WardIso solved the problem. Why is it like that? Thank you for all the effort. I love your terrain contributions
WardIso is a lighting technique and by default it is off, which it shouldn’t be really. There is also Minnaert but I haven’t enabled that.
Glad you like the terrain!
More features to come too
I have actually fixed this bug in the regular (non-splatting) shader and forgot about terrain lighting.
Now its fixed in SVN
oh cool, thanks Momoko
Small question (I’m still very new at using TerraMonkey’s features)
To use 12 textures splatting with TerrainLighting.j3md, do you need to overlay 3 different alpha maps?
This may be something done automatically done using the SDK and the TerranMonkey plugin, but project constraints prevent me from doing so.
Yes you need 3 different alphamaps. TerrainTestAdvanced shows you how (although it just shows 2 right now). The SDK also handles this for you automatically: it will create the alpha maps and edit them for you when you use the painting tools.
Thanks!
Considering the game I’m working on is completely unshaded. What kind of modification to TerrainLighting.j3md would be needed to make it an unshaded material?
Would it be more efficient to simply use an ambient light?
Unshaded.j3md
TerrainLighting.j3md isn’t necessarily specific to terrain, it is really just a texture splatting material that is most often used for terrain. There is nothing stopping it from being used on a box or just a quad.
So I assume I would need to modify the unshaded material files so it allows the use the terrain splatting and alpha-maps.
oh I see
You can use Terrain.j3md if you don’t want lighting. It, however, only supports 4 textures.
That material will disappear eventually however when I merge unshaded capability into the TerrainLighting material. Really that should happen sooner rather than later.
Thanks! 4 textures should be sufficient for now, else I’ll just make a custom material 
Thanks for implementing this. We’re using it actively for our port to jME3. We have however hit a small speed bump, that may be fixable with simple logging/documentation.
The LWJGLRenderer forces the maximum amount of bound textures to be 16. Wouldn’t it be a good idea to add a check in the Material class that warns the developer when more textures are added than is possible? We hit the 16 texture limit when using the terrain shader. Every DiffuseMap has its own corresponding NormalMap. This is to ensure that the terrain looks different in structure for roads, grass, sand, etc. We use more than 8 different types of terrain types in our terrain, meaning that we have more than 8*2 textures being bound to the terrain. This causes an ArrayIndexOutOfBoundException.
Is there another way to allow us this amount of textures? If not, we can work around it, but it would have saved some debugging time if jME had given a severe warning that we had tried to bind more than the maximum allowed number of textures.
You can use more textures by using TerrainGrid, where each cell in the grid is its own TerrainQuad tree and will have its own material, with 16 textures. You just have to match up the edges with the alpha maps. Eventually I am going to make TerrainGrid the default implementation in the terrain editor in JMP, with support for painting across many cells.
There might be a way to throw a warning that you have used too many textures, I will have to look into it.
So far I have been using only 3 splat textures, but I am about to increase this amount to get more detail and new feature variations, but I am wondering a bit about the performance hit when you use more splat textures. Anyone care to elaborate on this? Is the shader wired to handle this with no impact on performance?
I am thinking about using some normals as well so I guess I better choose wisely which ones since there can be maximum 12 textures or 12+1 normal from what I read. 2 Alpha + 8 Diffuse + 6 Normal sounds like a good combination since as you say Sporleg, you can have a different set for each TerrainQuad. This also goes for the TriPlanar Mapping which could be used on some TerrainQuads when they are important and removed on others to get better performance in those areas.
You will see minimal performance impact since it is all handled in the shader. TriPlanar mapping does have a noticeable performance hit since the terrain is essentially being rendered three times, but still all handled in the shader.
You are correct on the limit of normals and diffuse maps.
I do want to increase the texture count by using 3d textures or texture arrays. There will be some quirks about that but it should allow for a heck of a lot more textures.
Well I think 12 textures is very good as you are allowed 12 per TerrainQuad so if you partition your game world a bit I think it should be more than enough in my opinion. Although I guess I will see in time.
I had a quick look at the frag and I see that there is a lot of #ifdef, each adding to the calculation of the diffuseColor and naturally similar for the normals. So these calculations are just optimized immensely in the GPU, and will not have much impact on performance? If so that is good news! - I will definitely get some more layers going on. I think terrains can look very good with at least one noise-layer to add variation, its something that could even have been procedurally generated on the GPU if possible, but I guess a simple tileable texture will also do wonders. It might be that even just small touches of a standard dirt texture would add enough variation to reduce the tiling-effect one easily get from same textures over and over.
A new gtx 560 Ti card is on its way as well so I am sure that will also help a bit.