PBR Terrain Shaders - Basic & Advanced versions

If you have questions, just ask.

Probably the key is to get the POM right. Perhaps you could share with us your latest/greatest POM?

Also, make sure that the repository is a Maven repository, not Generic/RPM/Debian/etcetera.

1 Like

Here’s the link to my most recent attempt at setting up the repository, specifically the 3.3 version. Does the naming/versioning pattern look better, or would you suggest I change it?

I think I finally figured out how to upload to a specific folder and solved the “cannot locate pom” error, but the POM may still be messed up because I have now got an error saying that the POM is invalid when I tried to get the link from JCenter again.

Since I changed the naming and versioning structure of the project a few times trying to solve the first file location issue, It is likely that I have an incorrect value in my POM that I’ve overlooked

2 Likes

I took a quick look and didn’t see any obvious problems.

1 Like

Hmmm that’s strange it’s still not working for me then.I cleaned the repository up, deleting some files and removing the 3.2 version for now, so I’m only working with one jar and POM rather than 2 until I figure it out.

I think I will have to remake the repository again, as I converted it to some other non-POM based format when I pressed “link to jcenter” and pressed the wrong check box next to the “POM Project” checkbox.

I googled the issue, and found some people saying that my POM might require a n SCM variable as well, but I could not figure out what I should put in there, and I notice that the POM for some of yours and Pual’s bintray projects do not contain that, so I’m not sure if that will solve it anyways…

Just to make sure I’m still on the right track - it is okay that my github repository does not match the package structure of my maven project? Because I have my github project named PBR-Terrain but the project package in bintray is called PBRTerrain without the dash.

I am also only uploading a single jar, specifically the assets jar because this project is only shaders, and contains no java code. I assume this would not be causing the issue since its still a jar file, but I thought I should mention it just in case.

Unless you’re using the automated importer (“Import from GitHub” in the web interface) it shouldn’t matter how the GitHub repo is organized or named. You don’t need a GitHub repo to use JFrog/BinTray/JCenter.

What issue are you seeing that you think might be due to no Java code?

A few thoughts…

Caching can cause all sorts of confusion if you’re not wary of it. If you’ve tested a v1.0.0 and then deleted or changed it, the old v1.0.0 is probably cached on your development machine. While debugging the repo, you might try bumping the version number after every change.

Also, note that you can test your package in Gradle before linking it to JCenter, by using something like:

repositories {
    maven { url 'https://dl.bintray.com/yarnmcdonuts/aaaagames' } // for PBRTerrain
    jcenter() // for everything else
}

Finally, while a repo name like “aaaagames” is good enough for BinTray, JCenter will require that the repo name contain a dot ("."), such as “com.aaaagames”.

1 Like

Oh I see better now - this clears up a lot of past confusion I’ve had about the gradle build process. So technically I could post that dependency link to the JMEStore, but by including it in JCenter then it will make it easier for users to include in their gradle build file. So I will still work on getting it on JCenter since that seems to be the more optimal choice.

I forgot about the requirement for a “.” in the name as you previously mentioned. But I also hesitated to use com.aaaagames because I do not own the domain for aaaagames.com. I do however have aaaagames.net, so would it be okay to name my package “net.aaaagames” instead of “com.aaaagames” or does it have to be com?

I also see that the JMEStore is no longer visible… I was going to post this as soon as I make the new repository with the “.” in the package name - but I noticed 2 days ago that it appeared to be hacked and redirected to a page that just said “hello how are you” and I message Jayfella - however I have not heard back and it is starting to look like it may have been intentionally taken down… hopefully in the next few days it will become more clear what exactly is the situation.

Regardless of the state of the current store, I think it would still be useful for JME to still include a list of important JCenter and maven links in the same fashion as the store previously did - even if it is not as pretty and well formatted as the previous store, a similar but more simplified list of useful dependency links in the wiki for user contributions would be almost as good as the previous store page.

My main game project is still in the SDK and does not use gradle, but now that I am coming to understand gradle and its dependency system better, I am very excited to convert my game to a gradle project using your SDK Gradle Template in the near future.

2 Likes

It does not have to be com. net, org, gov, etc. all fine and pervasive.

Any domain will work but if it’s not one of the public ones that make sense like github, sourceforce, etc. then you have to own it to use it.

2 Likes

Ditto what Paul said about “com” and other TLDs.

I don’t what happened to JmonkeyStore or whether its loss will prove permanent. I’m “on break” from JME until 4 November. After that, I might pursue your suggestion of a simple list of Maven-accessible, JME-related libraries.

For library projects, I generally create a Gradle root project with several sub-projects: one for the library itself, one for sample apps, one for assets, and so on as needed. BasicGame-on-Gradle is for an application (not a library!) and doesn’t have sub-projects, so it’s not the best template for you to imitate this time.

Also, in case you get “fed up” with BinTray/JCenter, you might try deploying via GitHub Packages. I haven’t used it myself, but there’s a Maven option, and from the instructions it looks a lot simpler than BinTray.

1 Like

The maintainer left abruptly and killed the server on the way out… we still have backups and stuff so it’s recoverable. I think we (the all-collective we) are getting close to having it back online again. (I’m just a spectator but I see the activity.)

Not ideal to have happened the way it did but it’s probably for the best in the long run, I guess.

4 Likes

I’ve used GitHub Packages a bit on the Chipmunk project. I’ve had no major issues with it, but one downside is that even if your packages & project are public your build script must authenticate with GitHub to fetch packages. It’s not a big deal, but it is an inconvenience when the packages are public anyway. Here’s what my repo config looks like:

maven {
		url 'https://maven.pkg.github.com/MyWorldLLC/Chipmunk'
		credentials {
			username project.findProperty("githubUser") ?: System.getenv("GITHUB_USER")
			password project.findProperty("githubToken") ?: System.getenv("GITHUB_TOKEN")
		}
	}

You can either embed your GitHub credentials in the build file (not a good idea!), pass them as properties on the CLI when you invoke Gradle, or set them as environment variables (this is what I do, as it’s the easiest to deal with - you can just set it and forget it).

3 Likes

Any news regarding PBR terrain shaders?

The basic one is all done and working for both 3.2 and 3.3

And I’ll be uploading the better shaders for the advanced version very soon as well. The advanced one for 3.2 is done, and I am actually in the process of finally upgrading my game to 3.3, and then I’m going to upload the advanced version for 3.3 as soon as I confirm its working. Going forward, I’m also going to only release for 3.3 so it will be easier for me to manage and keep organized - so I’m going to reorganize my project on BinTray one more time and I think this time I should have it right so I can get the JCenter link as well.

I’m also working on a video to showcase the visual results of the advanced terrain, and to show how to make a quick advanced shader with code and with my editor. Then if there’s any community interest in my editor, I may continue with releasing that in the near future.

5 Likes

PBR Terrain finally climbed to the top of my to-do list. I apologize for taking so long to follow up.

I found your BinTray repo and was glad to see that a version had been released. The POM seemed okay, but the JAR wasn’t in the expected location, so I was unable to fetch it using Gradle. (The JAR was named “PBRTerrain-jme3.3-1.0.0-assets.jar” instead of the expected “PBRTerrain-jme3.3-1.0.0.jar”.)

I cloned your GitHub repo to get the example app and the assets. However, I haven’t successfully run the app yet. Here’s the latest console output:

Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'EMISSIVEMAP' mapped to non-existent material parameter 'EmissiveMap', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_0' mapped to non-existent material parameter 'Alive_0', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_1' mapped to non-existent material parameter 'Alive_1', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_2' mapped to non-existent material parameter 'Alive_2', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_3' mapped to non-existent material parameter 'Alive_3', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_4' mapped to non-existent material parameter 'Alive_4', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_5' mapped to non-existent material parameter 'Alive_5', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_6' mapped to non-existent material parameter 'Alive_6', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_7' mapped to non-existent material parameter 'Alive_7', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_8' mapped to non-existent material parameter 'Alive_8', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_9' mapped to non-existent material parameter 'Alive_9', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_10' mapped to non-existent material parameter 'Alive_10', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'Default':
Define 'ALIVE_11' mapped to non-existent material parameter 'Alive_11', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'PreShadow':
Define 'DISCARD_ALPHA' mapped to non-existent material parameter 'AlphaDiscardThreshold', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'PostShadow':
Define 'DISCARD_ALPHA' mapped to non-existent material parameter 'AlphaDiscardThreshold', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.material.plugins.J3MLoader readDefine
WARNING: In technique 'PostShadow':
Define 'DISCARD_ALPHA' mapped to non-existent material parameter 'AlphaDiscardThreshold', ignoring.
Jan 25, 2021 6:37:23 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[main,5,main]
com.jme3.asset.AssetNotFoundException: MatDefs/ShaderLib/MaterialFog.glsllib
	at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:371)
	at com.jme3.shader.plugins.GLSLLoader.loadNode(GLSLLoader.java:102)
	at com.jme3.shader.plugins.GLSLLoader.load(GLSLLoader.java:199)
	at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:260)
	at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:374)
	at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:387)
	at com.jme3.material.TechniqueDef.loadShader(TechniqueDef.java:512)
	at com.jme3.material.TechniqueDef.getShader(TechniqueDef.java:527)
	at com.jme3.material.logic.DefaultTechniqueDefLogic.makeCurrent(DefaultTechniqueDefLogic.java:59)
	at com.jme3.material.logic.SinglePassAndImageBasedLightingLogic.makeCurrent(SinglePassAndImageBasedLightingLogic.java:93)
	at com.jme3.material.Technique.makeCurrent(Technique.java:152)
	at com.jme3.material.Material.render(Material.java:1011)
	at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:614)
	at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:266)
	at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:305)
	at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:877)
	at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:779)
	at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1108)
	at com.jme3.renderer.RenderManager.render(RenderManager.java:1158)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:272)
	at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:530)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:632)
	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)

jme3-core has a “MaterialFog.glsllib” but it’s located in “Common/ShaderLib” not “MatDefs/ShaderLib”. Is that the same thing?

If you’re still interested in this project, I’m interested in helping it along. Let me know!

2 Likes

Yes that must have been a mistake that made it into the 3.3 shaders - fog support was not in core with 3.2 so I copy/pasted the file from common to my project. I think I made things confusing by trying to keep a working 3.2 and 3.3 version of the terrain shader while I was still on 3.2

But since I’m finally upgraded to 3.3 I’m going to focus only on that version and also finally get the maven repository working properly.

I initially uploaded only the assets jar, since the project is only shaders located in the asset folder(aside from the test case, which I overlooked).

Is there a way to tell it to include both the jar and the assets jar? Or is there a way to build both into a single jar when I build the jar with gradle prior to uploading it?

1 Like

The issue with the fog library path should now be fixed on the PBRTerrain master branch, and I also uploaded the finished versions of PBRTerrain and AdvancedPBRTerrain working with JME 3.3; let me know if you have anymore errors and I’ll be glad to fix it asap.
I’ll also have some more info and a new test case for the advanced shader soon in a seperate post, but first I want to focus on the maven repository and make sure that is all working now.

I made a new repository in a new package that follows the naming scheme that you had reccommended in an earlier post, and decided to abandon the past one since it got a bit sloppy with my attempts at trying to troubleshoot the “invalid pom” and since I was working with 2 versions at the same time.

https://bintray.com/beta/#/yarnmcdonuts/net.aaaagames/PBRTerrain?tab=files

<dependency>
<groupId>yarnmcdonuts.net.aaaagames</groupId>
<artifactId>PBRTerrain</artifactId>
<version>1.0.0</version>
<type>pom</type>
</dependency>

implementation 'yarnmcdonuts.net.aaaagames:PBRTerrain:1.0.0'

I believe I uploaded all of the jars into the correct directories, and I think that their site was updated since my last attempt, because it also gave me an option to auto-locate my files to match my pom when i uploaded it. But still I receive an error that says “invalid pom” when I try to link to JCenter, so I think something in my POM file still must not match the repository.

1 Like

I recommend building classes and assets into a single “fat” JAR.

1 Like

Again, the POM and the class/asset JAR should have the same name (up to their extensions, of course). I’m seeing 3 files in the 1.0.0 release:

  • AfflictedPBRTerrain-1.0.0-assets.jar
  • AfflictedPBRTerrain-1.0.0.jar
  • PBRTerrain-1.0.0.pom

That’s not going to work.

1 Like

What would you recommend as the best way of doing this when building with gradle? I’m not great with gradle, and my current gradle build file is actually based off of the one included in the SimArboreal library, which appears to split the assets jar like so.

dependencies {

    compile "org.jmonkeyengine:jme3-effects:3.3.+"
    compile "org.jmonkeyengine:jme3-core:3.3.+" 
    compile "org.jmonkeyengine:jme3-terrain:3.3.+" 

	
	runtime files("assets")

}

task assetsJar(type: Jar) {
    classifier = 'assets'
    from file('assets')
    exclude '**/*.psd' 
    exclude '**/.backups' 
}

artifacts {
    archives assetsJar
}
1 Like

I think things would go easier if you moved the assets from “assets” to “src/main/resources”, which is the standard location for assets in a Gradle project. Then you wouldn’t need the “assetsJar” task.

1 Like

I relocated the assets as you suggested, and I just uploaded a new, single jar to the repository titled “PBRTerrain-1.0.0.jar”

I also fixed the naming mismatch that was appending “Afflicted” to the name, but am still getting the invalid pom error.

I looked at the pom file for one of your projects hosted on Bintray, and unless I’m missing something it appears that my pom is following the correct format. I think I am locating it in the wrong directory on bintray, but I’m accepting the sites recommended target directory so I also don’t think that’s the issue.

I tried changing the groupId to no longer include “yarnmcdonuts.” infront of it, as I noticed that your pom file omits your user Id prefix - but I still am getting the invalid pom error with both attempts
<groupId>net.aaaagames</groupId>
<groupId>yarnmcdonuts.net.aaaagames</groupId>

The only difference between our pom files is that I noticed yours includes things in a dependency bracket <> but mine does not