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
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.
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)
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:
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.
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.
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?
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.
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.
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.
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 . 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.
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.
@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.
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).