jMonkeyEngine v3.7 feature freeze

Hi Everyone,
jMonkeyEngine v3.7 release branch was forked today from master and by that we are entering the feature freeze phase in which only bug fixes will be streamed to the next release. New features can still be merged to master as usual though.
With the release branch, a new jMonkeyEngine v3.7.0-alpha3 release was created and is available for testing.
There is a release page containing the engine updates which are included in this version (related to alpha2 ).

A basic gradle script for testing the alpha3 version will be something like this:

plugins {
    id 'java'
}

version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

def jme3 = [v:'3.7.0-alpha3', g:'org.jmonkeyengine']
dependencies {
    compile "${jme3.g}:jme3-core:${jme3.v}"
    runtime "${jme3.g}:jme3-desktop:${jme3.v}"
    runtime "${jme3.g}:jme3-plugins:${jme3.v}"
    runtime "${jme3.g}:jme3-lwjgl:${jme3.v}"

}

Cheers! :slight_smile:

12 Likes

I have updated my product build gradle to v3.7.0-alpha3 and minie 8.0.0 and got the following exception when trying to load a GLTF model:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Mar 13, 2024 7:19:09 PM com.jme3.bullet.objects.PhysicsRigidBody rebuildRigidBody
INFO: Created 291f7130fe0.
Mar 13, 2024 7:19:09 PM com.scenemaxeng.projector.SceneMaxApp handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.NoSuchMethodError: com.google.gson.JsonParser.parseReader(Lcom/google/gson/stream/JsonReader;)Lcom/google/gson/JsonElement;
	at com.jme3.plugins.gson.GsonParser.parse(GsonParser.java:46)
	at com.jme3.scene.plugins.gltf.GltfUtils.parse(GltfUtils.java:72)
	at com.jme3.scene.plugins.gltf.GltfLoader.loadFromStream(GltfLoader.java:124)
	at com.jme3.scene.plugins.gltf.GltfLoader.load(GltfLoader.java:107)
	at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:274)
	at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:390)
	at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:441)
	at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:446)
	at com.scenemaxeng.projector.SceneMaxApp.loadModelSpatial(SceneMaxApp.java:1813)
	at com.scenemaxeng.projector.SceneMaxApp.loadModel(SceneMaxApp.java:2091)
	at com.scenemaxeng.projector.SceneMaxApp.instantiateVariable(SceneMaxApp.java:1426)
	at com.scenemaxeng.projector.InstantiateGraphicEntityController.run(InstantiateGraphicEntityController.java:32)
	at com.scenemaxeng.projector.CompositeController.run(CompositeController.java:87)
	at com.scenemaxeng.projector.SceneMaxApp.simpleUpdate(SceneMaxApp.java:2937)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:263)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:163)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:225)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:245)
	at java.base/java.lang.Thread.run(Thread.java:834)

It looks like there were changes in the GsonParser (maybe we upgraded the parser for the new release?)

WDYT?

2 Likes

perhaps a consequence of PR 2183

2 Likes

What do you think Stephen, should we roll back the gson lib or adapt the assets manager to use the new gson lib?

3 Likes

It looks easier to roll back to gson v2.9.1, but the decision is up to you.

3 Likes

The problem was that I was using JME3.5.2 which probably worked against Gson earlier than 2.9.1 (I think 2.8.1 or earlier) then I have upgraded to v3.7-alpha3 and I had (for some reason) gson 2.8.1 lib which collided with the gradle import. I just removed the gson lib from the lib folder and everything worked fine. I think it’s best if possible to avoid the import of jars from the lib folder and work with gradle as much as possible to avoid this kind of crashes

1 Like

After the upgrade to alpha3.1 My app crashed a few times because one of my custom shaders had this code:

uniform sampler2D m_ColorMap;

varying vec2 texCoord;

void main(){

  vec4 color = texture2D(m_ColorMap, texCoord);
  gl_FragColor=color;
}

And after fixing it to this coe:

uniform sampler2D m_ColorMap;

in vec2 texCoord;
out vec4 fragColor;

void main(){

    vec4 color = texture2D(m_ColorMap, texCoord);
    fragColor=color;
}

everything worked fine.
We should use in/out params instead of varying

3 Likes

While testing alpha v3.7 I see that one of the GLTF models I’m using is now loaded with some missing textures (I think).

Here is the original model at mixmao web site:

And this how it looks when loaded to JME:

It’s a regression which occurs just after the upgrade.
Has anyone encountered a similar issue?

2 Likes

Hi @adi.barda , I did a test with Erika’s 3d Mixamo model in gltf format, and jme-3.7.0-SNAPSHOT and the textures all look ok.

Edit:
I noticed, however, that there is a difference:
here is the log of jme-3.7.0-SNAPSHOT

mar 25, 2024 10:59:36 AM com.jme3.scene.plugins.gltf.UserDataLoader apply
WARNING: Unhandled input type:class com.jme3.scene.plugins.gltf.PBRMetalRoughMaterialAdapter
mar 25, 2024 10:59:37 AM com.jme3.scene.plugins.gltf.UserDataLoader apply
WARNING: Unhandled input type:class com.jme3.scene.plugins.gltf.PBRMetalRoughMaterialAdapter
mar 25, 2024 10:59:37 AM com.jme3.scene.plugins.gltf.UserDataLoader apply
WARNING: Unhandled input type:class com.jme3.scene.plugins.gltf.PBRMetalRoughMaterialAdapter
mar 25, 2024 10:59:37 AM com.jme3.scene.plugins.gltf.UserDataLoader apply
WARNING: Unhandled input type:class com.jme3.scene.plugins.gltf.PBRMetalRoughMaterialAdapter
mar 25, 2024 10:59:37 AM com.jme3.anim.SkinningControl controlRender
INFO: Hardware skinning engaged for RootNode (Node)
mar 25, 2024 10:59:37 AM com.jme3.anim.SkinningControl controlRender
INFO: Hardware skinning engaged for RootNode (Node)
mar 25, 2024 10:59:37 AM com.jme3.anim.SkinningControl controlRender
INFO: Hardware skinning engaged for RootNode (Node)
mar 25, 2024 10:59:37 AM com.jme3.anim.SkinningControl controlRender
INFO: Hardware skinning engaged for RootNode (Node)

Loading the model in jme-3.6.1-stable there are no warning logs and the reflections on the textures look different.

:thinking:

2 Likes

I have now changed my editor to also run on jME3.7.0-alpha3.
I am using lwjgl3.3.2 and Minie8.0.0.

Over the following few days I will be testing this combination a bit and I will give feedback here if any issue were found.

One issue I did find was that this version of jME did not come with the native files for lwjgl.
I hope this helps a bit.

2 Likes

But is this again that you are not using Maven release? Manually adding JARs?

Yes. I am using ant in the sdk.
However, if I download the project here: Release v3.7.0-alpha3.1 · jMonkeyEngine/jmonkeyengine · GitHub
and I extract the project and try to run jME examples I get the same problem.
Reason is, there is no native lwjgl libs.

2 Likes

Looks like they were there in the release ZIP with 3.6.1 at least. Not with 3.7.

1 Like

The difference is that jME3.6.1-stable.zip contains the JARs needed for LWJGL v2 whereas jME3.7.0-alpha3.1.zip contains the JARs needed for LWJGL v3.

I’m not 100% certain, but I think this is related to PR 2153 which (accidentally?) switched jme3-examples from using jme3-lwjgl to jme3-lwjgl3. I suspect this indirectly switched the “dist” task from using jme3-lwjgl to jme3-lwjgl3.

Ideally, the dist ZIP should contain the JARs for both LWJGL v2 and v3 (and for Android and iOS and VR as well). However, that would entail significant changes to the Gradle build scripts.

3 Likes

If it can only contain one it feels like it should be jme3-lwjgl3 even if that’s (sort of) a breaking change. jme3-lwjgl3 has been out long enough now.

(I’d also argue that gradle/maven is the way to go when consuming these, not the zip)

4 Likes

I don’t think changing a dependency indirectly alters the Gradle build; I’m trying to figure out if this issue has to do with this PR.

This PR solves this problem (zip):

@sgold, this problem is related to this PR (little but yes)

The reason for these problems is that jme3-lwjgl3 only loaded the dependencies at runtime and when compiling JME3 it did not export the jar files, this can be solved by changing the way of adding the dependencies:

api "org.lwjgl:lwjgl:${lwjgl3Version}:natives-windows"

Should we use jme3-lwjgl3 by default in the examples? (I think it’s already quite stable)

3 Likes

Yes and no. The examples have a Swing based test chooser. LWJGL 3 and Swing aren’t exactly the best of friends. Examples should be run with LWJGL 3, there is very little on jME side too what hasn’t been implemented. The said test chooser and the graphics settings selection aren’t. That might mean that someones first impressions are that the examples don’t run at all.

3 Likes