Finish Modularizing PBRTerrainUtils.glsllb #2377
Conversation
Previously I only modularized AdvnacedPBRTerrain.j3md But now this PR applies the same concept to PBRTerrain.j3md I ended up deleting the PBRTerrain.frag file, so now both of the terrain's .j3md files reference the same fragment shader, but the advanced version has a boolean called UseTextureArrays set to true to tell the fragment shader to read from texture arrays instead of normal textures. I also added suppor for metallicRoughnessAoEi maps in the regular PRRTerrain shader (Ao being ambient occlusion that is packed in blue channel, and Ei being emissiv intensity which gets packed in the alpha channel). You will still be limited to 16 textures without using texture arrays, and as always I'd suggest most people juts use the advanced version of the shader primarily, but atleast the option is there.
yaRnMcDonuts
changed the title
yaRnMcDonuts
changed the title
Removes the UseTextureArrays boolean, and instead map the define to the AlbedoTextureArray. This should be a cleaner way to do it that the define doesn't rely on users going back and setting a boolean on old terrain mats, and gives less chance to accidentally break the shader if the boolean value is cleared by mistake for some reason.
accidentally reverted triplanar to using wPosition instead of lPosition. probably doesn't matter, both should work (although high wPosition values could result in lack of float precision so its best to go with local instead of world)
|
I plan to merge this within the next 24-48 hours, then I'll cut the next alpha release. I might make some minor final changes if I run into errors testing things one last time tomorrow, but everything is solidified now and all redundant code is condensed into AdvancedPBRTerrain.frag and the PBRTerrainUtils glsllib. The only places that still have duplicate code are the 2 .j3md files, however there is no realistically clean way to combine both pbr terrain shaders into one .j3md file and I'd say it is best they still each have their own .j3md file anyways so that it is obvious that one is intended to use texture arrays and the other basic textures. |
|
Making a few more changes to add support for NORMAL_TYPE so that you can flip terrain normals by toggling the NormalType int param the same way its done in PBRLighting.j3md. |
|
Everything is fixed and thoroughly tested now. Both terrain examples run with no exceptions, and I ensured that the final render is identical in both triplanar and non-triplanar mode for both examples. (aside from the obvious intended differences expected from triplanar mode) I also tested everything in the Afflicted Forests (my own game) as well as my custom scene editor app, and I ensured that there were no exceptions or rendering issues there. But of course we will still need other jme devs with different devices to test this in the upcoming alpha release in case there's any device-specific exceptions or rendering issues that I did not find on my own device. Despite some fixes that improve the final render and improve the effects from normal maps, I'm still not satisfied with the final results of how things look in the terrain examples, but I think that has more to do with the free textures I used, and also the lighting settings. The examples could probably use a brighter light probe and a different direction set for the DirectionalLight (to help emphasize the low quality normal maps). But at least the examples still work to show how to use the shader, I suppose that's the important part. |
Previously I only modularized AdvnacedPBRTerrain.j3md
But now this PR applies the same concept to PBRTerrain.j3md
I ended up deleting the PBRTerrain.frag file, so now both of the terrain's .j3md files reference the same fragment shader, but the advanced version has a define that gets set to true to tell the fragment shader to read from texture arrays instead of normal textures.
I also added suppor for metallicRoughnessAoEi maps in the regular PRRTerrain shader (Ao being ambient occlusion that is packed in blue channel, and Ei being emissiv intensity which gets packed in the alpha channel). You will still be limited to 16 textures without using texture arrays, and as always I'd suggest most people juts use the advanced version of the shader primarily, but atleast the option is there.