jME 3.9.0-alpha5 was released 2 nights ago. Ther are very few changes relative to alpha4, so this is planned to be the final alpha version of 3.9 prior to beta1. The most notable change is the addition of the new thread warden feature (thanks to @richtea) that will help make troubleshooting the dreaded “scene graph updated form another thread” exception much easier, especially for new users who are unfamiliar with the exception and its cause. Full release notes here: Release jMonkeyEngine 3.9.0-alpha5 · jMonkeyEngine/jmonkeyengine

I found the following article illuminating: Ars Technica – 1 Dec 25 ### After 40 years of adventure games, Ron Gilbert pivots to outrunning Death Interview: Storied designer talks lost RPG, a 3D Monkey Island, “Eat the Rich” philosophy.

My most complex terrain so far. In both shapes and texture blending.

Here’s some screenshots from a dark scene that I’m using as a testing ground for a VectorEffect system that I’ve been working on. The system leverages jME’s existing easing library to create an effect system that runs easing and noise effects directly on a ColorRGBA, Vector3f, Vector2f, or Vector4f object with a variety of togglable parameters. This eliminates the need for repetitive boiler plate code for things like flickering or pulsing lights, particle emitters, and any other color or vector-based parameters. I still have a few things to finish before the system is fully ready to be demonstrated in a video or gif. So in the meantime, here are some screenshots showing my recent progress:

And for sub-projects, gradle has the advantage that they are genuine sub-projects and not just some hacked in wiring around “separate projects in the same directory structure” like for maven. If you rebuild just a gradle subproject, it knows which other sub-projects to rebuild and tracks the dependencies for it correctly. It’s possible that if you use an IDE then it will gloss over some of maven’s multi-project ugliness but it will never be as good at gradle is at tracking dependencies. So if you are still in the “undecided” camp, gradle is the more modern option. If you are already using gradle, you probably already have a settings.gradle file in the root. After creating the sub-project subdirectories, add new subprojects in settings.gradle. To have one sub-project depend on another, add the dependency in build.gradle like for any other jar except use `project(:foo:bar)` as the dependency. Here is an example of a settings.gradle file for a simple multi-project build: github.com/jMonkeyEngine-Contributions/zay-es #### settings.gradle `78d4045f3` // To declare projects as part of a multi-project build use the 'include' method include 'extensions:Zay-ES-Net' rootProject.name = 'zay-es' // More sensible sub-project names project(":extensions:Zay-ES-Net").name = "zay-es-net" …it has the advanced application of renaming the sub-project, too… if for some reason you want/need different sub-directory names than sub-project names.

You usually use a build system like Gradle or Maven. Both these support creating subprojects or submodules. You can check their documentation online. In general you will have a root folder for your project and then your subprojects will have their own folders. I’m a Maven guy and I also do subprojects. Example: my-game-project-folder/ sub-project-server/ pom.xml sub-project-client/ pom.xml sub-project-common/ pom.xml sub-project-editor/ pom.xml pom.xml Then in my pom file I list them as modules so Maven knows they are submodules. <modules> <module>sub-project-server</module> <module>sub-project-client</module> <module>sub-project-common</module> <module>sub-project-editor</module> </modules> Then in sub-project-server if I need stuff from sub-project-common I can add it as a dependency: <dependencies> <dependency> <groupId>com.myproject</groupId> <artifactId>sub-project-common</artifactId> <version>1.0.0</version> </dependency> </dependencies> For Gradle it’s similar but on the Gradle way (meaning you need to edit different files). Gradle Docs - Multi Project Builds Maven - Multi Module Builds

What build system are you using? If it’s gradle you can create a new gradle module

This maybe a bit of a silly question, but I never bothered to find out how I should setup sub projects in my Java-project and it is becomming a mess now. Here is the scenario: I am working on a new project, a game. To create content for this game, I want to create a number of editors. I think these editors should be sub projects in my main project, but I have no clue how to set this up. Can someone recommend to a good (video) guide to learn how to do this?

Looking good! It’s always nice to see all the layers of a good looking VFX.

I’ve made a video demonstrating how to create this effect, and here are some shader files for the magic portal. Feel free to use them if you’re interested. drive.google.com ### Portal.zip Google Drive file.

That looks good, can we see it in motion?

Twitter/x has been running a deal on the monthly verified subscription, usually its $8 a month but currently is just $1 for the first month. So I decided to try it out and see if it helps get anymore reach on the engine’s x account. From what I am reading, being verified _does_ help boost your replies when commenting on other posts. It sounds like one of the best ways to build a following on twitter is to frequently reply to other popular game dev related posts (important to be done respectfully, of course), and the verified badge should greatly help with this. I also signed up for verified on my own twitter account for my game, since it’s just a dollar. If anyone else is interested, they are running the $1 subscription sale until tomorrow night. At the end of next month, I will then assess whether the verified subscription is worth it for the jMonkeyEngine account, and if so then I will continue paying the $8 monthly fee using our funds from jME’s donations on open-source collective. This will run us about ~$96.00 a year at 8.00 per month. And of course I would like to hear community input on this matter. If anyone opposes this idea, or if you do not think it is a good use of jME’s funds, then please feel free to speak up and voice your concerns. The last thing I want to do is use the community funding for something that the community doesn’t agree on, so please do not hesitate to speak up with your opinions on this matter.

Recently, I learned a little about shaders and tried to create a magic portal for my game.

More modeling practice.

Join me tonight at 8PM GMT-5 (day late and an hour earlier than normal) as I try to figure out why some static objects have messed up collisions. Mythruna - “Collision Debugging” Live Stream https://www.youtube.com/live/0fj8wBE1vuk?si=LTfMTvXfs6osQQIF

I also experienced this settings difficulty with my recent adventures in JME-Android world. Most ways of interacting with settings get ignored because the AndroidHarness substitutes its own settings object based on its own parameters. However, there are a bunch of settings in AndroidHarness that _end up in_ its own settings object. This would be how you would set the audioRenderer to null public class AndroidLauncher extends AndroidHarness { public AndroidLauncher() { appClass = MyApplication.class.getCanonicalName(); audioRendererType = null; // <-- add this } } If you look at the source of AndroidHarness you can see how each parameter goes into the settings object. Not everything has an equivalent AndroidHarness parameter but a lot of things do

Minie v9.0.2 was released yesterday. It addresses a couple minor bugs and is based on JME 3.8 instead of 3.7 .

M_L_Jeevanandhan: > settings.setAudioRenderer(null) Where did you put it? I don’t know much about Android development but I’m pretty sure that the main() method is not run on Android… which is where most examples of turning off audio would have put that line. For Android apps, I think it needs to go in a different place… but that’s definitely how you’d disable it.

I’m developing a jMonkeyEngine 3.8.0 Android app in Android Studio, and I keep getting this crash on the GL thread: java.lang.IllegalArgumentException: newLimit > capacity: (1 > 0) at com.jme3.audio.openal.ALAudioRenderer.initOpenAL(...) It happens as soon as OpenAL Soft initializes. I do **not** want to use OpenAL at all on Android — only OpenSL ES or the Android MediaPlayer/SoundPool backend. I’ve tried things like: * `settings.setAudioRenderer(null)` * not using any AudioNode * removing audio settings completely …but JME still tries to load OpenAL Soft on Android and crashes every time. **How can I completely disable OpenAL Soft on Android or force JME to use a different audio backend (`ANDROID_OPENSL` or `ANDROID_MEDIAPLAYER`)?** Any known workarounds or patches for JME 3.8.0? Thanks!

trying to design gui… turns out programming is much easier than drawing hope to show a fully functional GUI on next monthly WIP

awesome! i was waiting for this

Thanks for your reply, @TesterY. I really appreciate it. The filter is now working correctly. The important thing is not to change the background color (default = black) of the `ViewPort`. That was the cause of the problem I was having. Another optimization you can add to the filter is to avoid continuously creating a new `SceneGraphVisitor` in the `postQueue()` method, but rather to create a single class variable that can be reused each time. @Override protected void postQueue(RenderQueue queue) { Renderer renderer = renderManager.getRenderer(); // 1. Render objects to the mask FrameBuffer renderer.setFrameBuffer(maskFrameBuffer); renderer.clearBuffers(true, true, true); // Render each selected spatial using the mask material for (Spatial sp : selectedSpatials) { sp.depthFirstTraversal(maskVisitor); } // 2. Pass the generated mask texture to the final filter material this.material.setTexture("MaskTexture", this.getMaskTexture()); // 3. Reset the FrameBuffer to the main viewport output renderer.setFrameBuffer(viewPort.getOutputFrameBuffer()); } private final SceneGraphVisitorAdapter maskVisitor = new SceneGraphVisitorAdapter() { @Override public void visit(Geometry geo) { renderManager.setForcedMaterial(maskMaterial); renderManager.renderGeometry(geo); renderManager.setForcedMaterial(null); } };

I’ve just released version 3.0.0 of Tamarin. The big new feature is Android support! I.e. running locally on a Quest or similar android based headset. [Obligatory AI generated image of an Android Tamarin to break up the wall of text] # Technical details on OpenXR bindings Modern VR is implemented using OpenXR calls to the VR runtime, LWJGL doesn’t have android bindings for OpenXR (only desktop bindings) and there are no java android bindings (inexplicably!) only c bindings. So as part of this I’ve created my own java-c bindings for openXR. You can use these with any java project, they aren’t dependent on either Tamarin or JMonkeyEngine (but obviously do use Tamarin and JMonkeyEngine!) This binding is available at github and is called TamarinOpenXrAndroidBindings. It it available as a maven/gradle dependency: com.onemillionworlds.tamarin:openxr-bindings-native. This uses code generation based on parsing the c header file so covers the whole OpenXR spec, not just the bits I needed for Tamarin (but only the bits I used for Tamarin are tested). It is a thin binding (just like LWJGL) so it mirrors the C calls one for one (and so is a nightmare to use). Realistically you don’t need to care about this but it took _ages_ so I want to mention it ## Better Hand Bone Simulation On desktop I was getting the hand bone positions from the runtime even when holding the controllers. This doesn’t seem to work on Android (it seems with the right magic spells it might be possible, but I don’t want to hold up the release trying to get it to work). In PC VR I have basic Tamarin supplied hand bone simulation as a fall back, as it will be the primary source for bones in android I have improved it for version 3. It now uses both the trigger and grip pressure as inputs so can make pointing gestures as well as grabbing gestures It has to be explicitly set up (to give the TRIGGER and GRIP handles) VRHandsAppState vrHands = new VRHandsAppState(handSpec()); vrHands.setSkeletonSynthesiser(new DefaultSkeletonSynthesiser(ActionHandles.TRIGGER,ActionHandles.GRIP,SkeletonSynthesiser.SynthesiseMode.FALLBACK_ONLY)); getStateManager().attach(vrHands) ## Project structure As part of this I’ve broken the project into 4 published maven dependencies * Tamarin Core: big module containing most of the features of Tamarin * Tamarin (aka Tamarin Desktop): wires in LWJGL calls for openXR * Tamarin-Android: Wires in Tamarin OpenXR native bindings for OpenXR * Tamarin OpenXR bindings: Provides OpenXR thin binding for Java You mostly don’t need to care about the structure as the transitory dependencies are brought in for you. But if you were trying to target both PCVR and Android you’d want your main module to have tamarin-core as its dependency and a module each for PCVR and Android using the appropriate Tamarin version in each ### Desktop If you’re using desktop just depend on com.onemillionworlds:tamarin as before (as well as jmonkeyEngine of course) There is a sample application at TamarinTestBed ### Android If you’re using android just depend on com.onemillionworlds:tamarin-android (as well as jmonkeyEngine of course) There is a sample application at TamarinTestBedAndroid (I’m a bit new to Android so suggestions for improvement appreciated) ## Conclusion Feedback and bug reports are as always very much appreciated. I’ve tested on a Quest 3 but no other devices

Tnx… what I did for now is downgrade JME to 3.7.0 and that worked. It is a workaround, I think @RiccardoBlb is right and it is due to a Wayland-problem. But for now this works and I will try the next JME version later on.

Hi @Fedor_van_Eldijk This problem could be external to the engine; as far as I know, glwf dynamically loads the libdecor library at a low level, and if it doesn’t find it, it doesn’t load it. Its main function is to manage the top bar of the graphics windows. As @RiccardoBlb mentions, you can force a change in Wayland as long as you have enabled XWayland to use X11, as follows (JME 3.9.0+): public final class App extends SimpleApplication { public static void main(String[] args) { App app = new App(); AppSettings settings = new AppSettings(true); settings.setX11PlatformPreferred(true); app.setSettings(settings); app.start(); } }