I am not at my computer to post up my code or upload my converter class, but tomorrow I could post my code, or if you’d like to try the converter class, I could post that to gtibhu and you can see if it works in your project, since you don’t need to worry about the fact that it doesn’t interface with the SDK yet.
1 Like
thanks, i will wait for tomorrow.
currently i will try find out why PBR_ComputeDirectLight is missing.
edit:
it kind of not load #import “Common/ShaderLib/PBR.glsllib”, because there is PBR_ComputeDirectLight. Even checked my lib version and this method is there…
it say about overload so i belive params then are wrong
ok i kind of got it why you do this crazy things. 
I had a moment after getting home to upload the files to github and got rid of the parts that depended on my project, so it should hopefully work alright, otherwise I can revise it again once I am awake tomorrow.
There’s a jar with a single class called “TerrainShaderConversion” that should be able to convert a phong terrain to my PBR shader, and theres also the shader files in the assets folder if you’d prefer to reference those
I should also note that i didn’t finish tri-planar mapping in the fragment shader.
1 Like
as i see your “converter” is just changing material/materialParams usage, nothing else.
i thought you change shader or something itself
i will look at shader and see what differences it have to find what issue i have about PBR_ComputeDirectLight.
about shader material change i would design it via 2 files that extends some abstract method(that have remove material, apply material methods and texture managing method)
It does change the shader, but you have to initiate it with the proper asset paths. just designate the starting shader, as well as the shader you want to change to
it should make your terrain appear as pbr if you just call these two lines
TerrainShaderConversion terrainConversionRelationship = new TerrainShaderConversion("MatDefs/shaders/AfflictedPBRTerrain.j3md", "MatDefs/shaders/TerrainLighting.j3md");
terrainConversionRelationship.convertToPbrOnLoad(yourTerrain, assetManager);ok, thanks, i will investigate your code further, but anyway i need design it different way because i also got it customized. so i will just see what must be done to make a fix.
if this work, then its enough for me thanks
Not yet but its close to being done, I got distracted and left a few loose ends untied after I got the standard texture mapping mode finished
1 Like
Has your issue been solved?
true issue? not ;/ there are only alternatives.
seems there is some issue in TerrainLighting about normals.
1 Like
I tried to investigate the standard phong terrain shader some more to find where the problem lies, and I think I may have made some progress. But I’l probably have to do more testing against the master version of the TerrainShader to see if I can figure out how to fix it.
It looks like TerrainLighting.frag is only accounting for ambient light. If you get rid of the ambient light part of the final lighting calculation, the terrain goes black - so it must not be receiving any directional lights somehow
So changing this code…
gl_FragColor = AmbientSum * diffuseColor +
DiffuseSum * diffuseColor * light.x +
SpecularSum * specularColor * light.y;
to omit the ambient light calculation like so…
gl_FragColor = // AmbientSum * diffuseColor +
DiffuseSum * diffuseColor * light.x +
SpecularSum * specularColor * light.y;
causes the terrain to be unlit 
DiffuseSum does get calculated correctly, but it looks light the value of light.x and light.y is 0
Edit:
It looks like the real solution will lie in the vertex shader, where the light direction is calculated incorrectly it appears. Hard coding vLightDir as vec3 (0.1, 1.0, 0) makes the normal mapping very apparent
Did you hard code it before or after the tbnMat multiplication?
This is precisely the kinds of results I’d expect from a geometry with normal maps but no tangents.
After the tbnMat calculation.
I managed to fix the problem in the PBR terrain shader where tbnMat was used in the fragment shader. But it seems like I can’t figure it out in the vertex shader for the Phong terrain
Well now I’m thorooughly confused. I recreated a fresh terrain in the SDK to try and reproduce the problem from scratch, and the normal maps show up in the SDK as well as at run time for the Phong terrain.
But no matter what I cannot get my old terrains to show normal maps with the Phong terrain shader, even with the same material that works on the new terrain… The only diffference is that every other terain I have made was generated in JMB. But unfortunately there’s a bug in the newest windows version of JMB so I can’t add a new normal map to test the results in there…
Have you used Jmonkey builder for generating or editing your terrains at all? Or just the SDK?
I’m wondering if it is a bug in JMB (or possibly the SDK as well, but I haven’t managed to trigger it
with yet with the new terrain I just generated)
I had this issue in the past, but never followed up since it did not affect the PBR version of my terrain at run-time
Here’s the normal map working with a new terrain generated in the SDK… so maybe it isn’t an error in the shader after all, I’m not sure now…
1 Like
Normal maps require tangents in the mesh.
My guess is that your JMB created terrain doesn’t have tangents and the SDK one does. Super-duper-duper-duper easy to check in code.
Not sure how many other “it’s probably tangents” hints we can really drop though.
I tried generating the tangents manaully in the SDK and still get the issue.
Is this the type of check you mean? If so then it appears as though the “broken” terrain does have some values in its tangent buffer. Do these values look standard for a tangent buffer? (they all have a z value of 0 but I don’t know enough to know if that is standard for tangent values)
ArrayList<TerrainPatch> lisst = new ArrayList();
((TerrainQuad)terrain).getAllTerrainPatches(list);
for(int c = 0; c <tans.length; c++ ){
System.out.println(" FFFF " + tans[c]);
}
}
snippet of the output:
FFFF (1.0, -0.0, 0.0)
FFFF (0.9997491, -0.02239602, 0.0)
FFFF (0.9998822, -0.015344265, 0.0)
FFFF (0.99999315, 0.0036983034, -0.0)
FFFF (0.9999891, 0.0046595926, -0.0)
FFFF (0.99999714, 0.0023536596, -0.0)
FFFF (0.99999976, 7.2288455E-4, -0.0)
FFFF (0.9999998, -7.2288455E-4, 0.0)
FFFF (0.99999714, -0.0023536596, 0.0)
FFFF (0.9999947, -0.003261549, 0.0)
FFFF (0.99902576, -0.044131156, 0.0)
FFFF (0.9996347, -0.027028402, 0.0)
FFFF (0.9999877, -0.004958924, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (1.0, 0.0, 0.0)
FFFF (0.9996705, 0.025670396, -0.0)
FFFF (0.9986199, 0.05252057, -0.0)
FFFF (0.99855834, 0.053679213, -0.0)
FFFF (0.99856305, 0.05358995, -0.0)
FFFF (0.99857, 0.053458907, -0.0)
FFFF (0.9985807, 0.053259492, -0.0)
FFFF (0.9985984, 0.052927118, -0.0)
FFFF (0.998631, 0.052307893, -0.0)
FFFF (0.99870026, 0.050968554, -0.0)
FFFF (0.9988844, 0.04722434, -0.0)
FFFF (0.9994419, 0.03340739, -0.0)
FFFF (1.0, -0.0, 0.0)
FFFF (0.99944186, -0.033407386, 0.0)
FFFF (0.9997674, -0.021565357, 0.0)
FFFF (0.9999987, 0.0015583017, -0.0)
FFFF (0.999999, 0.0013771041, -0.0)
FFFF (0.9999999, 6.6566456E-4, -0.0)
FFFF (1.0, 2.002716E-4, -0.0)
FFFF (1.0, -2.0027162E-4, 0.0)
FFFF (0.9999998, -6.656645E-4, 0.0)
FFFF (0.99999946, -9.3078567E-4, 0.0)
FFFF (0.99979997, -0.020000271, 0.0)
FFFF (0.99995005, -0.010000636, 0.0)
…hmmm… thought JME used four element tangents.
I mean, you can test my hypothesis in two ways:
- modify the shader to use a fixed TBN matrix and see if you see different results (ie: see some lighting/normal maps)
…or… - compare the tangents from your working terrain to the non-working terrain and see if something looks odd.
im using just the SDK
tried both SDK and code-based terrain. both dont work
@pspeed i think yaRnMcDonuts know every normals need tangents. no need repeat it.
the fact is terrain have calcNormals control and i thought it calculate it automatically.
Anyway like said before, generating tangents in code create more artifacts
so here i should repeat “generating tangents dont help”
Yes, your case is clearly different.
I only repeat it in the context of testing hypotheses because it fits every one of his clues so far.
Fact:
-terrain he creates in SDK works fine
-terrain he creates in JMB doesn’t
-the same shaders are used
-broken JMB terrain shows no directional lighting (sign of bad tangents)
-hacking the shader to bypass the TBN calculation showed some directional lighting (sign of bad tangents)
-only thing different between working and not working is the j3o.
So other than material parameters… seems like the only difference to check is in the mesh. But I guess based on what you’re saying, maybe the JMB Terrain is missing some controls.
Dumping both j3os as XML might be enlightening.