jMonkeyEngine v3.7.0-alpha1 - updates

Development Engine Development
1

Hi Everyone,
Unless there are last minute changes, jMonkeyEngine v3.7.0-alpha1 will enter a feature freeze phase on Monday, Mar-11-2024 at that point a release branch will be created where we can run our tests and prepare for production.
There is a release page containing the engine updates which are included in this version. I’m regularly updating this page.
While in feature freeze phase, new features / fixes can be streamed to “master” branch as usual but only fixes to features included in the coming release will also go to the release branch and eventually to production.

I would like to thank everyone assisting with this release - the PR contributors and anyone who answers my questions in private / GitHub (sorry if I’m asking too much questions :slight_smile: ).

As some of you may already know, currently:

  • There are just a few regular contributors
  • We have 1 regular contributor to the core engine
  • There is no system architect to the project

I think we need to address those points, encourage more dev. to contribute and have one or more architects to decide whether or not a given PR is aligned with JME standard & vision / roadmap especially features/fixes which introduces changes to the interface and/or with high impact.

As a starter for solving those issues I created a code reviewers form (my private form, not official JME) where you can specify ways you can assist in the PR code review process.

Thanks a lot!

14 Likes
2

Thank you for publishing the alpha release, scheduling feature freeze, and articulating what the project needs. Thanks also for all your behind-the-scenes work that brought us to this point.

8 Likes
3

Thank you all for the great work that has been done!

@adi.barda There are some already approved PRs that I have submitted that I would like to see in version 3.7.0.

They are small changes I suggested while developing the material editor with the Lemur library to work with @yaRnMcDonuts and @codex on shaders.

These 4 do not introduce any new features, I just formatted the code according to the code style adopted by jme. No risk of breaking with past, present and future code.

This PR introduces only 5 new constants (Vector2f.NAN, Vector2f.UNIT_X, Vector2f.UNIT_Y, Vector2f.POS_INF, Vector2f.NEG_INF) to conform the class to existing constants in the Vector3f and Vector4f classes. No changes to the internal code. No risk of breaking with past, present and future code.

Please let me know what you think about it.

Thanks.

Edit:
There is also a strange, still unsolved case that I reported about a method of the AbstractShadowRender and AbstractShadowFilter class.

5 Likes
4

It’s not a breaking change but this one needs an engine architect review. personally I wouldn’t add anything which is not in real use but I’m not familiar with JME coding standard & best practices. This is a good example for a case which needs an architect decision.

1 Like
5

Thanks for raising this issue. I commented in GitHub

2 Likes
6

I am your friend @adi.barda. I am glad you are managing the release of the next version of the engine. According to your list, I am one of the few regular contributors. I have been using the engine for about 8 years, I have opened dozens of Issue, proposed PR and helped with code review. Here is my YT portfolio :wink:

I was writing an editor for Material and came across this use case for the Vector2f, Vector3f and Vector4f classes. That’s why I opened the PR.

    private void parseInto(String text, Vector2f storeResult) {
        ...
        storeResult.set(Float.NaN, Float.NaN); // Why ??? Because Vector2f.NaN does not currently exist.
    }

    private void parseInto(String text, Vector3f storeResult) {
        ...
        storeResult.set(Vector3f.NaN);
    }

    private void parseInto(String text, Vector4f storeResult) {
        ...
        storeResult.set(Vector4f.NaN);
    }
2 Likes
7

My preference would be for any class that needs Vector2f “constants” to declare its own private ones. This practice improves reliability and simplifies debugging, since a class that accidentally modifies such fields won’t break other classes.

In my libraries, I avoid the public Vector3f and Quaternion constants, for exactly this reason. For example:

However I’m not strongly opposed to adding static fields to Vector2f because:

  1. my coding style is idiosyncratic and might not be optimal in every situation, and
  2. the proposed changes wouldn’t force anybody to use the new constants.
4 Likes
8

Thank you :slight_smile: I’m 100% your friend too. I think I understand better the motivation now. I totally appreciate and trust your code but since I don’t have much (any) knowledge in the the engine’s architecture / best practices , whenever I see a suggested change to the core classes especially to the interface, I need an engine core dev approval before I merge.

3 Likes
9

Hi Everyone. jMonkeyEngine v3.7.0-alpha1 binaries are now published to mavenCentral so anyone can consume them for testing in their gradle scripts for example:

plugins {
    id 'java'
}

version '1.0-SNAPSHOT'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

def jme3 = [v:'3.7.0-alpha1', 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!

7 Likes
10

I have tested and Tamarin isn’t compatible with 3.7.0-alpha1. This is because of the upgrade from LWJGL 3.3.1 to 3.3.3. (Tamarin adds lwjgl-openxr which uses some classes (StructBuffer) from core lwjgl).

But this isn’t a problem, I can see what I need to do and I’ll release a new tamarin to go with the new JME version. I’ve started a compatibility table because this might start to get confusing

4 Likes
11

With 3.7.0-alpha1, I’ve begun seeing new and unexpected assertion failures when geometries move out of the camera’s frustum due to camera rotation. I mention it in case others encounter similar failures.

Here’s a typical stack trace:

Mar 01, 2024 6:39:53 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[jME3 Main,5,main]
java.lang.AssertionError: Invalid Matrix4f value Matrix4f
[
 NaN  NaN  NaN  NaN 
 NaN  NaN  NaN  NaN 
 -2.3273895E-4  -4.6547787E-4  4.654778E-4  0.9998042 
 0.0  0.0  0.0  1.0 
] for WorldViewProjectionMatrix
	at com.jme3.renderer.opengl.GLRenderer.updateUniform(GLRenderer.java:1390)
	at com.jme3.renderer.opengl.GLRenderer.updateShaderUniforms(GLRenderer.java:1516)
	at com.jme3.renderer.opengl.GLRenderer.setShader(GLRenderer.java:1758)
	at com.jme3.material.logic.DefaultTechniqueDefLogic.render(DefaultTechniqueDefLogic.java:97)
	at com.jme3.material.Technique.render(Technique.java:168)
	at com.jme3.material.Material.render(Material.java:1089)
	at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:678)
	at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:273)
	at com.jme3.renderer.queue.RenderQueue.renderShadowQueue(RenderQueue.java:283)
	at com.jme3.shadow.AbstractShadowRenderer.renderShadowMap(AbstractShadowRenderer.java:451)
	at com.jme3.shadow.AbstractShadowRenderer.postQueue(AbstractShadowRenderer.java:422)
	at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1221)
	at com.jme3.renderer.RenderManager.render(RenderManager.java:1292)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:283)
	at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:631)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:721)
	at java.base/java.lang.Thread.run(Thread.java:829)

The crashes are highly reproducible. I haven’t opened a GitHub issue yet and am working to create a simple test app and hopefully identify the root cause.

EDIT: possibly related to shadows
EDIT2: opened issue 2209
EDIT3: already @RiccardoBlb has provided a fix

4 Likes