jMonkeyEngine v3.8.0-alpha3 released

A new 3.8.0-alpha3 release is available for testing:

project.ext {
  jmeVer = '3.8.0-alpha3' 
}
dependencies {
    implementation "org.jmonkeyengine:jme3-core:$jmeVer"
    ...
}

Full Release Notes Here

I am planning for the first 3.8 Beta version to release in approximately 1-2 weeks unless any major issues are reported that cannot be resolved in time.

So the cut off point for new features and major changes being added to 3.8 will be February 12th, at which point the main priority of 3.8 will be to focus on bug fixing and code cleanup.


With that said, there are only 4 things to note that have changed since alpha2, and not too much new to test:

  • Updated to LWJGL 3.3.4

  • Refactoring related to the new Multiple Monitor support. However I have also found some potential issues caused by MultipleMonitor support, so I will make a thread about this soon.

  • The old monolithic version of PBRLighting.frag has been deleted, and the new modular version of PBRLighting has replaced it. It is functionally the same, but now much more organized and easier to fork.

  • AdvancedPBRTerrain is now modularized, however PBRTerrain is temporarily broken until it is also modularized (which I will do once AdvancedPBRTerrainā€™s modular approach receives further testing and is finalized). So please focus any terrain related testing on AdvancedPBRTerrain.j3md, and avoid using PBRTerrain.j3md until the next release.

So If youā€™d like to help test alpha3, it would be especially helpful to test the new Multiple Monitor support, AdvancedPBRTerrain.j3md, and any other standard PBR models.

And thank you to everyone that has helped contribute and test this release so far :slightly_smiling_face:

14 Likes

I found an embarrassing regression in -alpha3 and submitted a fix: PR #2362.

Please try to get 2362 included in the next test release.

Also, I have a trivial PR from last month that is overdue to be integrated: PR #2347

4 Likes

Iā€™ve found another regression, parallax mapping was never tested with the new modular PBR, so it throws an exception if you load a model with a parallax map.

I overlooked this in my previous testing because I donā€™t use parallax anymore and havenā€™t for a long time, but luckily one single model in one of my old scenes still used it and managed to reveal this issue.

If anymore severe bugs are reported I may push out another alpha release prior to the next beta. Otherwise weā€™ll go straight to beta in about a week.

4 Likes

I ran into something in alpha3. One of my models has a parallax map packed in a normal map, but jME fails when I try to set PackedNormalParallax to true.

The error is on line 978 (undefined variable ā€œwViewDirā€). It tries to access wViewDir outside its scope. The error does not occur in alpha2.

    Material mat = geometry.getMaterial();
    mat.setBoolean("PackedNormalParallax", true);

Results in:

Feb. 09, 2025 5:20:05 PM com.jme3.renderer.opengl.GLRenderer updateShaderSourceData
WARNING: Bad compile of:
1	#version 150 core
.
. (error log truncated to fit in hub)
.
950	
951	    PBRSurface PBRLightingUtils_createPBRSurface(in vec3 wViewDir){
952	
953	        PBRSurface surface;
954	        surface.position = wPosition;
955	        surface.viewDir = wViewDir;
956	        surface.geometryNormal = normalize(wNormal);
957	
958	        return surface;
959	    }
960	
961	    #ifdef ENABLE_PBRLightingUtils_readPBRSurface
962	        vec2 newTexCoord;
963	        
964	        void PBRLightingUtils_readPBRSurface(inout PBRSurface surface){
965	
966	            surface.bakedLightContribution = vec3(0);
967	            surface.directLightContribution = vec3(0);
968	            surface.envLightContribution = vec3(0);
969	
970	            #ifdef ENABLE_PBRLightingUtils_getWorldTangent
971	                vec3 tan = normalize(wTangent.xyz); 
972	                surface.tbnMat = mat3(tan, wTangent.w * cross( surface.geometryNormal, tan), surface.geometryNormal);
973	                surface.hasTangents = true;
974	            #endif
975	
976	            
977	            #if (defined(PARALLAXMAP) || (defined(NORMALMAP_PARALLAX) && defined(NORMALMAP)))
978	                vec3 vViewDir =  wViewDir * surface.tbnMat;  
979	                #ifdef STEEP_PARALLAX
980	                    #ifdef NORMALMAP_PARALLAX
981	                        //parallax map is stored in the alpha channel of the normal map         
982	                        newTexCoord = steepParallaxOffset(m_NormalMap, vViewDir, texCoord, m_ParallaxHeight);
983	                    #else
984	                        //parallax map is a texture
985	                        newTexCoord = steepParallaxOffset(m_ParallaxMap, vViewDir, texCoord, m_ParallaxHeight);         
986	                    #endif
987	                #else
988	                    #ifdef NORMALMAP_PARALLAX
989	                        //parallax map is stored in the alpha channel of the normal map         
990	                        newTexCoord = classicParallaxOffset(m_NormalMap, vViewDir, texCoord, m_ParallaxHeight);
991	                    #else
992	                    //parallax map is a texture
993	                    newTexCoord = classicParallaxOffset(m_ParallaxMap, vViewDir, texCoord, m_ParallaxHeight);
994	                #endif
995	            #endif
996	            #else
997	            newTexCoord = texCoord;    
998	            #endif
999	
.
. (error log truncated to fit in hub)
.
1495	void main(){
.
. (error log truncated to fit in hub)
.
1539	}

Feb. 09, 2025 5:20:05 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[#36,jME3 Main,5,main]
com.jme3.renderer.RendererException: compile error in: ShaderSource[name=Common/MatDefs/Light/PBRLighting.frag, defines, type=Fragment, language=GLSL150]
0(978) : error C1503: undefined variable "wViewDir"

	at com.jme3.renderer.opengl.GLRenderer.updateShaderSourceData(GLRenderer.java:1659)
	at com.jme3.renderer.opengl.GLRenderer.updateShaderData(GLRenderer.java:1686)
	at com.jme3.renderer.opengl.GLRenderer.setShader(GLRenderer.java:1751)
	at com.jme3.material.logic.SinglePassAndImageBasedLightingLogic.render(SinglePassAndImageBasedLightingLogic.java:277)
	at com.jme3.material.Technique.render(Technique.java:168)
	at com.jme3.material.Material.render(Material.java:1099)
	at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:842)
	at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:772)
	at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:273)
	at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:315)
	at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:1117)
	at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:1012)
	at com.jme3.renderer.pipeline.ForwardPipeline.pipelineRender(ForwardPipeline.java:117)
	at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1313)
	at com.jme3.renderer.RenderManager.render(RenderManager.java:1355)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:283)
	at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:707)
	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:797)
	at java.base/java.lang.Thread.run(Thread.java:1575)
4 Likes

Thanks for testing and reporting this! I will work on a fix and post back here soon to request review of the PR (and a few others).

It also looks like the turncated error log you posted has coincidentally revealed another error in the shader code that I didnā€™t notice previously. Just by chance, this code was the first I saw when viewing your error log:

Some devices donā€™t like floats being declared like this, so these 3 vecs should instead be declared as vec3(0.0); in decimal format.

Iā€™ve been trying to spot these little shader errors like this, but I inevitably miss some since they donā€™t cause issues on my device. So if anyone is reviewing this shader code, be on the lookout for any places like this where you see any floats that are not in decimal format.

Edit: this pr should solve the parallax issue, and it also fixes some incorrect float declarations:

6 Likes

A user reported issues with Spline serialization, and investigation uncovered another issue in that area.

These appear to be old bugs, not regressions. They seemed fairly easy to solve, so I filed a quick PR to solve them. I would love to see PR 2368 included in v3.8.0.

Also, note that PR 2347 and PR 2362 are still awaiting integration.

5 Likes

Hereā€™s a final list of additional PRs that I plan to merge before moving to beta.

I will leave these open for final review over the next 4-5 days.

Then, unless any unresolvable concerns are raised, I will merge these PRs and create the next release this weekend.

If thereā€™s any other finished PRs that Iā€™ve overlooked that anyone would like to see make into 3.8, now would be the last chance to mention them.

4 Likes

There is a one for JmeSurfaceView. The issue was first-reported 2 years ago.

2 Likes

Hi @yaRnMcDonuts ,

Iā€™ve reviewed two PRs and left my comments.

Please take a look at them when you get a chance.

Thanks for all your hard work!

2 Likes

This PR looks good to me from a code standpoint, however I have no experience using jme for android dev so I canā€™t speak from a functionality standpoint.

In this case, I will still merge your PR as long as you have tested it yourself to guarantee that the issue is fixed and that there are no other apparent issues caused as a result of thie PR.

It would be optimal to have atleast 1 more person who is experienced with android dev review this PR from a functionality standpoint, as it is always good to have a second opinion from someone equally knowledgeable in that area.


However this is inevitably an issue with any open source project relying on volunteer work, and it may very well be that you yourself are the only jme dev knowledgeable in that area who is currently active at this time.

I know this has put me in a similar position where Iā€™ve been merging some of my shader related PRs without as much review as Iā€™d like. But to compensate, I have been assuring I heavily test the functionality of all my PRs to minimize errors, and Iā€™ve been making sure that I am only merging things that I am willing and able to maintain and address bug fixes for in the near future.

If anyone has issue with any of this, feel free to speak up, as I am still new to the release manager position and I am open to feedback in regards to my approach and methodology so far.


I also may delay merging these PRs for a few more days than I initially said, Iā€™ve come down with a fairly bad sickness over night and its the type that has me feeling scatter brained and struggling to focus, so I am going to hold off on doing much else for at least a day or two until I feel better.

3 Likes

I believe @Anuj_Topiwala had the opportunity to test it. This PR addresses a specific issue and will not address other optimizations and/or issues if exist. However, if required I might be able to publish a side-load jme3-android release on my GitHub packages for someone else to testā€¦

yeah, I understand, take some rest, we arenā€™t on a hurry, are we?

2 Likes

The testing that youā€™ve already done from you and another android user should be more than enough to assure there arenā€™t any major issues with the codeā€™s functionality.

And further testing on more devices will inevitably occur once the PR is merged and integrated into the next few alpha/beta releases for testing.

1 Like

I found another regression in 3.8ā€™s new PBR implementation.

It looks like the light probe blending is no longer working based on the hard edges where 2 terrain patches are meeting:

It looks like it is still blending on a per-geometry basis, so I probably just need to find somewhere in the lighting code where its incorrectly inputting the geometryā€™s origin position rather than the pixelā€™s world position to determine the blend weight between overlapping probes.


Also here are a few more PRs for review:

This 3rd PR upgrading LWJGL could specifically use testing from anyone with VR hardware, so if anyone can help with this it would be greatly appreciated.

6 Likes

I have another PR I could use feedback on. This attempts to fix an android issue that has caused crashes since 3.7 related to the addition of precision qualifiers for shader varTypes.

I knew practically nothing about these precision qualifiers up until 2 hours ago, but I am fairly confident this solution (or something similar) will solve the crashes on android while maintaining the highest precision supported on both desktop and android devices.

So feedback from anyone knowledgeable in this area would be greatly appreciated. :slightly_smiling_face:

4 Likes

I apologize for the delay being longer than I said, I got way sicker than I expected but Iā€™m finally back to near 100%. I tried working on a few little things here and there, but not much.

Now Iā€™m working on finishing the last parts of the PBRTerrain shaders and then Iā€™ll work on putting out one more final alpha release (rather than going to beta) and I hope to have that uploaded within a week.

However I did make the mistake of trying to upgrade my pc to use a new SSD while I was recovering from being sick, and I ran into problems and now thatā€™s the main thing delaying me from finishing the PBR terrain shaders. I naively expected setting up a new SSD to be a breeze despite being sick, and now Iā€™m struggling to get my primary PC working again with a fresh windows install :sweat_smile:. I know its unrelated to jme dev, but I may post back here requesting some help/advice on how to get my PC to detect the windows install on this SSD if I keep struggling with this.

6 Likes

I ran into Windows problems before concerning boot configurations while using Ubuntu (it seems that something happens on the windows side that has dropped the configuration files pointing to the C:\Windows\Boot).

If you have the ability to boot into the Windows Recovery Screen; then you can update the boot configuration by pointing it to the new drive using BCDBOOT utility, itā€™s available via the recovery cmd.

This is a git-gist for my fix.

Sorry for the unrelated links. Hope it helps.

1 Like

@pavlg With all due respect I believe you will need to request a more experienced member to either test/build/suggest changes on internal of engines/ upgrades/ bugs resolving. I mostly have limited experience in this regard and mostly work at application level.

1 Like

I am open to anyone who would like to offer help in that regard, and you already did a good job catching the issue. Just to know, the new version will ship a bug fix to the Java Heap Memory Leaks and not the native heap (this is another issue).

2 Likes