PBR Terrain & Converter Utility

Also anyway @yaRnMcDonuts need to change license of it, because it cant be used as new BSD as it is now with license file inside. Strict law related. (“All rights reserved.”)

I will most likely clean up all of the extra (and unused in 3.3) vars for daylight and indoor lighting when 3.3 is moved to stable, but until then I will probably leave support for both so that i can have day/night cycles in 3.2 still

Yeah it should be okay to remove these from the final version if it gets merged into the engine. But for nowm they shouldn’t affect your code as long as they are not defined.

I set that up a long time ago, and actually copy/pasted many things with the license and gradle files from another repository I was referncing, but I’ll remove that licensing. I’m still somewhat of a noob with using Gitbhub :stuck_out_tongue:

2 Likes

Im testing your shaders.

Normals looks fine even in blend areas.

i fully dont understand this line:

  normal += norm * 0.9;

why there is:

mat3 tbnMat;

used only in:

plaguedNormal = normalize(tbnMat * plaguedNormal);

?

also one i dont understand why:

normal = normalize(normal * vec3(2.0) - vec3(1.0));

instead of JME PBR one that is:

normal = normalize((normal.xyz * vec3(2.0, NORMAL_TYPE * 2.0, 2.0) - vec3(1.0, NORMAL_TYPE * 1.0, 1.0)));

?

BTW:

could you also implement normal intensity change:

  normal.z /= 10;
  normal = normalize(normal);

where 10 will be param.

it works here:

  normal += norm * 0.9;

  normal = normalize(normal * vec3(2.0) - vec3(1.0));

  normal.z /= 10;
  normal = normalize(normal);

Whenever I was working on it, I was also confused as to why I could not copy this code exactly from the standard PBR shader. But finally I had to just base it off of “what looks right” when the scene is rendered

So rather than basing my code directly on the original shader, I ended up trying many things with the Terrain’s tangents and normals until I finally got the PBR Terrain to appear in the scene the same way as a standard quad with the normal PBR Shader.

Whenever I have some time I’ll test this out and ensure it works as intended when applied to a terrain. Although for a terrain, there would have to be an option to change the intensity on a per-texture basis.

1 Like

Whenever I have some time I’ll test this out and ensure it works as intended when applied to a terrain. Although for a terrain, there would have to be an option to change the intensity on a per-texture basis.

yes, per texture, it would be again a lot params :slight_smile:

it should blend some intensity param based on texture params.

So rather than basing my code directly on the original shader, I ended up trying many things with the Terrain’s tangents and normals until I finally got the PBR Terrain to appear in the scene the same way as a standard quad with the normal PBR Shader.

hmm, would be great to have same as PBR, then it would be easy to “update based on PBR changes” in future. Also probably more issues were solved there.

also, there seems to be not so important issue in normals, just for 90 degree terrain:

Thankfully it should not be much of an issue when updating both files to new versions (atleast it was not for me when I was also developing a 3.3 version as well), as most updates to the PBR shader will only effect the lower half of both shaders (the liighting caclulations) wheras the top part of both PBR shaders (the texture reads) is already drastically different between the normal PBR shader and the terrain shader

That’s odd, did you double check that you turned tri-planar mapping on? it looks like the albedo texture is also stretched out as well - I haven’t noticed any distortion in my scenes but I will double check

hmmm…

the only thing i did was:

    mat_terrain.setBoolean("useTriPlanarMapping", true);

and i got no normals?

sorry, it more look like everything broke rather just normals.

do i need enable something more?

When using tri-planar mapping, you also need to adjust the scales for all of your textures.

So you need to divide all of your textures’ scales by the size of your terrain, if I remember correctly.

So on a terrain of size 512, a scale of 4.0 is equal to a scale of 0.007797271 in tri-planar mode.

If you make a terrain in the terrain editor, then it will automatically divide/multiply your scales when you toggle tri-planar mode, but you need to do that manually when you make terrains with code.

better now, but im still not sure if normals on 90 degree terrain are ok.

i tried each of

public Vector3f lightDir = new Vector3f(5.9236743f, -7.27054665f, 5.896916f);
public Vector3f lightDir = new Vector3f(5.9236743f, -7.27054665f, -5.896916f);
public Vector3f lightDir = new Vector3f(-4.9236743f, -3.27054665f, 5.896916f);
public Vector3f lightDir = new Vector3f(-4.9236743f, -4.27054665f, -5.896916f);

but always i see very low visible, or invisible normals on same side of mountain. idk why.

maybe its still just light, im not sure

They look correct from certain angles - although the issue with normal mapping on all models is that it depends on the lighting angle

If you want to exaggerate the normal map for testing purposes, try settings a low roughness value and a high metallic value. Normal maps are much, much more apparent on PBR models that are very shiney.

If you have a model with high roughness and a low metallic value, then you will notice more depth from the roughness map than the normal map.

I think you still have to normalise a mixed normal. I’m not sure that’s the actual issue, just noticed you never mentioned that step.

1 Like

just to show shader on multidimensional model:

all textures have same normalmap, for some reason left arm/hand have almost no normals.

same on front view, same arm/hand

maybe im just nervous about this normals. overall effect is ok, just not sure why its not same on both sides, since it use same texture scale and same normalmaps, just different albedos

Does your model also have a roughness, metallic, and AO map?

Alone, a normal map does not does not do as much as it may seem. I notice a drastic graphical improvement on any models that have an AmbientOcclusion map in addition to the normal map.

That’s why I am also working on a version of the shader to support texture arrays and allow for AO, roughness, and metallic maps - otherwise the terrain will never be as detailed as a standard model, as it can currently use only a normal and albedo map.

1 Like

trully, im not familiar with AO maps and im not sure how to do/use them.

my workflow was only albedo/normal/ (metal/roughtness) .

if you could tell me how to use this, and you say it look way better, im interested.

edit: ok im baking AO in blender cycles render, will see how it look

I learned how to utilize each map to its fullest potential by analzying the models on sketchfab using the “Model Inspector” button down at the bottom right of the model preview window. Even if you don’t purchase a model, you can still inspect it to see the individual albedo map, normal map, AO map, etc. - and then also view the final render

I spent alot of time looking at and inspecting models on sketchfab - comparing the ‘final render’ version of a model to what it looks like with only the ‘BaseColor’.

Although I guess that would be getting into a topic of its own, related to making the most of the PBR shader, and how the artist’s approach differs from the Phong workflow

1 Like

right,

anyway in earlier image i just used your terrain shader (it work in IDE because i have ShaderLibs in project)

not sure if AO will change something, but will try

1 Like

Glad to hear that the terrain is working for you now :slightly_smiling_face:

1 Like

hope you will grant us with official cleaned/upgraded version when 3.3 stable :slight_smile:

anyway, great work!

2 Likes