PBR Terrain Shaders - Basic & Advanced versions

Here is how it looks with “useTriPlanarMapping: false”


and here is how it looks with “useTriPlanarMapping: true”

This work is based on Opel GT Retopo by Thomas Glenn Thorne (aka “systmh”) licensed under CC-BY-NC-SA.

2 Likes

for a triplanar you need use much different texture scale. (its not same)

it will be much lower number.

2 Likes

Yes @oxplay2 is correct, and there is actually an equation for converting a normal scale to a triplanar scale based on the size of the alpha map.

I had forgotten about this, since I coded this conversion into my editor and it is also coded into the SDK terrain editor.

But here is some of my code I found for converting a normal terrain scale to a tri-planar scale (or also back to normal scale from triplanar) in a for loop for all of a terrain’s texture slots

          float alphaMapSize = material.getTextureParam("AlphaMap").getTextureValue().getImage().getHeight();
          for(int s = 0; s < 12; s ++){
               String scaleParamStringForSlot = "AlbedoMap_" + s + "_scale";
               MatParam scaleParam = material.getParam(scaleParamStringForSlot);
                if(scaleParam != null){
                    previousScale = (float) scaleParam.getValue();
                }

                if(useTriPlanarMapping){
                    newScale = previousScale / alphaMapSize;

                }else{
                    newScale = previousScale * alphaMapSize;
                }
                material.setFloat(scaleParamStringForSlot, newScale);
           }

Edit: I should also note that the terrain size could be used in place of the alpha map size… I’m honestly not sure which is correct, and in hindsight i think the terrain size should be used, but from my testing the alpha map size did work so I will stick with that for now until I’m able to test and compare both.
Although for myself it may be irrelevant because I always use the same sized terrain and alpha map(i.e a 512 size alpha map for 512 sized terrain,I’ve found any higher than a 1:1 ratio uses too much memory, and any lower looks pixelated).

1 Like

Better now. Thank you both!

1 Like

A new version titled 1.0.1 should be available now as well, and it shouldn’t have those warnings anymore.

1 Like

Better now. Thanks!

Any news about getting the repo linked to JCenter?

1 Like

No problem :slightly_smiling_face:

I tried pressing the “add to jcenter” button again and then proceeded without checking the “pom project” checkbox, and now instead of saying “invalid pom” it is saying "Failed to send a message: Package should include sources as part of the package."

1 Like

It’s possible JCenter won’t accept packages that aren’t in a compiled language. I’ve never tried that.

For PBRTerrain, I’d argue that sources and assets are the same thing. So you might try uploading a copy of PBRTerrain-1.0.1.jar under the name “PBRTerrain-1.0.1-sources.jar”.

1 Like

Uploading a copy titled “PBRTerrain-1.0.1-sources.jar” worked and when I linked to JCenter it said my message was sent this time, thanks!

Hopefully I will hear back from them soon saying that it was successfully linked to Jcenter, and then I’ll report back

1 Like

The library is finally linked to Jcenter and is now available on the JMonkeyStore as well

10 Likes

Thanks for making this available. I’ve begun using it in my projects. Please keep me informed of future releases.

2 Likes

JCenter will abandon us in May. Do you have plans to keep the library available beyond May 1st?

1 Like

Yes, I’ve been lightly following the thread about JCenter sunsetting, and briefly looked at the website for MavenCentral where you said you’ll be uploading your repositories.

I hope it will go more smoothly than my attempts at learning to use JCenter, but I will be glad to post this library up to maven central over the next few months if that is the optimal place.

2 Likes

I’m happy to help.

2 Likes

I just uploaded a new version 1.0.2 that is available on JCenter. I updated the basic shader (“AfflictedPBRTerrain.j3md”) to be able to use a lower version of GLSL (as low as GLSL100), so now it should run on mobile devices and older GPUs.

implementation 'net.aaaagames:PBRTerrain:1.0.2'

I had to get rid of some defines in the matdef file, as it appears GLSL150+ lets you use more than 64 defines; but thankfully there were many unused defines I had left there that could be removed, so the version could be lowered without any actual changes to the shader functionality.

The advanced version will still require GLSL150+ for texture arrays and unfortunately that is not something that can ever be lowered as far as I’m aware, thus the advanced shader will always be unreliable for mobile devices and older GPUs, and is better suited for larger scale desktop games. But that is why I will still be maintaining the basic version of the shader without texture arrays as well

3 Likes

Posted a new version to JCenter to fix a crash error and clean up some of the unused code and comments from when I was in the thick of the dev process on these shaders a while back.

implementation 'net.aaaagames:PBRTerrain:1.0.3

I’ll also likely work on figuring out how to post to maven central for any future versions.

1 Like

HelloMav crashed when I tried v1.0.3:

com.jme3.asset.AssetLoadException: An exception has occurred while loading asset: /Materials/Vehicles/Mountains.j3m
	at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:262)
	at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:374)
	at com.jme3.asset.DesktopAssetManager.loadMaterial(DesktopAssetManager.java:395)
	at com.jayfella.jme.vehicle.examples.worlds.Mountains.load(Mountains.java:98)
	at com.jayfella.jme.vehicle.World.attach(World.java:97)
	at com.jayfella.jme.vehicle.simpledemo.HelloMav.simpleInitApp(HelloMav.java:113)
	at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:239)
	at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:513)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:625)
	at com.jme3.system.lwjgl.LwjglWindow.create(LwjglWindow.java:466)
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:463)
	at com.jme3.app.LegacyApplication.start(LegacyApplication.java:424)
	at com.jme3.app.SimpleApplication.start(SimpleApplication.java:127)
	at com.jayfella.jme.vehicle.simpledemo.HelloMav.main(HelloMav.java:92)
Caused by: java.io.IOException: The material parameter: ProbeColor is undefined.
	at com.jme3.material.plugins.J3MLoader.readValueParam(J3MLoader.java:422)
	at com.jme3.material.plugins.J3MLoader.readExtendingMaterialParams(J3MLoader.java:441)
	at com.jme3.material.plugins.J3MLoader.loadFromRoot(J3MLoader.java:771)
	at com.jme3.material.plugins.J3MLoader.load(J3MLoader.java:800)
	at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:260)
	... 13 more

1 Like

I removed the ProbeColor variable since its no longer used in 3.3 now that AmbientLight works for scaling a probe’s color.

And unfortunately that appears to have corrupted your terrain material, because the material still has a value defined to ProbeColor even though I’ve deleted that paramater in the shader.

I had this happen to me shortly after upgrading to 3.3 when I tried to rename many variables that had the word “Affliction” in front of them, but apparently that caused all of my terrains with embeded materials to no longer load, with the same error you listed.

The error can only be soved by recreating the terrain, or directly editing its material file if it is not embedded into the terrain… or if I were to add the unused ProbeColor variable back to the .j3md file it would fix it, which I could do for you although it isn’t a clean solution, and I think this points to a bigger error in JME.

I think this may be a new problem with the engine in 3.3 (or I somehow never noticed it prior) -eitehr way, I do not think that removing a paramater from a shader’s .j3md file should cause the material to throw an error and no longer load. I am fairly certain that I have done this in JME 3.2 without it breaking my material…

I am thinking I should make another thread about this issue, as it will also prevent JME’s stock PBR and Phong shader from ever removing any variables if someone commits a breaking change that needs reverted…

2 Likes

Removing “ProbeColor” from the material solved the issue. Thanks for the tip!

1 Like

A user on the JmonkeyStore reminded me that I never updated the store page to include a link to the AdvancedPBRTerrain test case. I just submitted an update fixing this, however there was no way to reply to or message this specific user to let them know, so I figured I should post an update in this thread. Thank you to “invokegs” for bringing this to my attention and I hope you can manage to find this update, as I could not find your username here on the hub to tag you @invokegs.

I also forgot to update this thread to mention that the most recent versions of the PBR Terrain Shaders have been officially merged into JME as of version 3.4, so if you are looking to use these PBR terrains with new version of JME, they are readily available in the Common/MatDefs directory for version 3.4+. The version on the JME Store is still useful for users running version 3.3 so I will leave that as is.

3 Likes