This latest version includes a few bug fixes, and all of the regressions that were reported during the alpha phase should now be fixed.
So now is a good time to try implementing the beta branch into your projects to check for any remaining issues and report back with your results.
I plan to move to stable only after a solid week or two of no new regressions being reported. It will also be useful to hear reports of any testers who run the beta with no issues to ensure that enough successful testing has occurred before stable.
I appreciate your work on the new release, but I have some doubts about the addition of the new jme3-screenshot-tests module. While I understand its potential value for image study and analysis, I have some concerns about its placement within the core engine.
Specifically, Iām wondering if it aligns with the primary needs of our developers. From my perspective, it seems to add files that everyone needs to incorporate into their local engine copies, which then require ongoing maintenance (making the job even more difficult for future release managers!). Given that it didnāt seem to generate significant community interest upon its initial introduction, and wasnāt utilized during the recent shader restructuring, Iām questioning if itās truly essential for the main project.
Perhaps we could explore alternative ways to manage this module, possibly as a separate project? This would allow those who find it useful to utilize it, while keeping the core engine streamlined.
The key benefit of having it be part of the main project is that a PR canāt be merged if it breaks the tests. Making it the problem of the person who broke things to either update the tests (if it really is better) or to fix it.
If it is a seperate library then that makes it someone elseās problem to retrospectively unbreak what someone else broke (which is often the case today with things found in manual tests). My hope is that if these tests are expanded we can release more quickly without risking more bugs (i should find some time to write some, but help is always appreciated). This should make things easier for future release managers not harder.
I agree with the sentiment that more testing is better.
However I also have to point out that most of the regressions that did occur were related to a near entire rewrite of jmeās PBR shaders, and it was expected that there would be more regressions in this area than usual during alpha testing. Especially considering it was a 2 person job where riccardo wrote up a quick initial draft for pbr with structs as an alternative to my design, and he specifically indicated that he had not done thorough testing himself and there were many mistakes in this quick draft. But he was busy and I still wanted to include his struct based design, so I accepted the task and did my best to keep the engine in alpha until I was confident that the new design was thoroughly tested.
Most of the pbr related regressions were actually just minor mistakes that he or I made in the rewrite process. And two pbr issues that I initially referred to as regressions actually ended up being long standing issues that were overlooked in the past that would not have been found had it not been for the extra testing I did as a result of this rewrite.
Overall, I am confident in the testing that has occurred throughout the 4 alpha releases, and the PBR shaders are in a better state than ever: the final render is closer to industry standards for pbr, there are less bugs than before, and it is more organized and more extensible than ever before.
I agree, there was already one situation where the screenshot tests found an issue with a PR that was otherwise overlooked by the other checks/tests on github. So I would say that these tests are a useful addition to the engine.
I did initially misunderstand how the screenshot tests work though, so maybe it would be useful to have some type of official write up or documentation that explains what the screenshot tests are doing and how to analyze their results, so that way their benefits will be more apparent.
I did not intend to criticize your work for this release, i was following the issue tracker and know how much work has gone into this.
It was a more general statement that the screenshot testing is a vital feature since it is most likely the only way to actually unit test a graphics engine.
So far there have been no issues reported with 3.8.0-beta1. So Iām planning to aim for the beginning of May for a stable release.
If anymore regressions or serious issues are reported before May, then that date may be moved back slightly. But so far Iāve managed to use 3.8.0-beta1 in all of my own projects with no issues, and I havenāt found any issues while running through jmeās examples. So between that and the lack of bugs being reported by other testers, I feel confident that 3.8.0 stable is very close to being ready.
I suspect that there is a problem with the deserialization of the DirectionalLightShadowFilter because the initialization of the material is in the constructor of the AbstractShadowFilter superclass, instead it should be in the AbstractShadowFilter.init() method as it is for all other filters [see here]. I am investigatingā¦
Material initialization should stay in the method below.
This thing probably causes problems to the SDK Scene editor as well, I am referring to the Filters section to save/load j3f files.
I found another set of bugs with the initialization, setting and cloning EmitterShape variables. I am investigating these as well.
If confirmed, these are defects already present in earlier versions of the engine and independent of recent evolutions.
Edit:
here is the test class to reproduce the error:
(probably the problem affects all xxxLightShadowFilter classesā¦)
apr 16, 2025 4:04:32 PM com.jme3.app.LegacyApplication handleError
SEVERE: Uncaught exception thrown in Thread[#23,jME3 Main,5,main]
java.lang.NullPointerException: Cannot invoke "com.jme3.material.Material.setTexture(String, com.jme3.texture.Texture)" because the return value of "com.jme3.post.Filter.getMaterial()" is null
at com.jme3.post.Filter.setDepthTexture(Filter.java:310)
at com.jme3.post.FilterPostProcessor.initFilter(FilterPostProcessor.java:192)
at com.jme3.post.FilterPostProcessor.reshape(FilterPostProcessor.java:520)
at com.jme3.post.FilterPostProcessor.initialize(FilterPostProcessor.java:171)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1184)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1298)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:283)
at com.jme3.system.lwjgl.LwjglWindow.runLoop(LwjglWindow.java:629)
at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:719)
at java.base/java.lang.Thread.run(Thread.java:1589)
apr 16, 2025 4:04:32 PM com.jme3.system.JmeSystemDelegate lambda$new$0
WARNING: JmeDialogsFactory implementation not found.
Uncaught exception thrown in Thread[#23,jME3 Main,5,main]
NullPointerException: Cannot invoke "com.jme3.material.Material.setTexture(String, com.jme3.texture.Texture)" because the return value of "com.jme3.post.Filter.getMaterial()" is null
16:04:33: Execution finished ':com.test.Issue_DirLightShadowFilter_Deser.main()'.
The error is also poorly worded, it is not clear which of the filters the error refers toā¦
Iāve addressed the issues raised in the previous reports with the following two fixes. Your review and feedback on these would be appreciated. Please let me know if any clarification is needed. I propose including these in the next release (3.8.0).
Furthermore, @toniheleās contribution (already reviewed and approved by @pspeed) is also suggested for inclusion in the 3.8.0 release.
Edit:
I am undecided whether to create a defensive copy of the Vector3f variables in the constructor and setter methods of the EmitterShape and ParticleInfluencer classes to prevent external changes from affecting the internal state of the classes. What do you think about this?
JME usually counts on callers to create their own defensive copies in many cases. (And when it doesnāt, it sometimes does it wrong, I think anyway.) I havenāt looked at the context in this case. We definitely want to avoid doing new Vector3f() every time something calls the setter (or getter).
Edit: I looked at the code in the PR and note that it might break existing code thatās expecting a shape position to be shared across multiple emitter shapesā¦ ie: any code that WANTS the change to be affected by external modification.
I think that itās best to hold off on any further changes to 3.8.0 unless we find any major breaking issues that absolutely need fixed. I am planning on having the stable release out very soon and donāt want to risk introducing any more regressions that could push that date back and require further testing.
Iām only in a slight rush because the maven central repo announced they will be requiring all projects to migrate from their OSSRH to Central Publisher Portal at the end of June ( OSSRH Sunset Announcement - Documentation), and I want to be sure that 3.8 stable is out well before that date to avoid any further delay that may be caused while weāre figuring out the migration process.
I will also be working on a 3.9.0 alpha release immediately following 3.8.0 stable and these PRs will be able to be integrated and can start being tested in the next alpha phase very soon, so with all things considered I donāt see a need to rush them into this release. But I will take a look at those PRs to merge them soon and to start adding them to a 3.9 milestone.
