(April 2022) Monthly WIP Screenshot Thread

Improved my menu and am ready to tackle that frightening customized keymap topic.


I was going to post this yesterday but it seemed too unreal to be posting on April 1st.

After nearly a decade, I finally released something else Mythruna-related: A backers-only test build so that folks who have been supporting me all of these years can play with the progress. (Backers = original Mythruna donators or patreon patrons.)

As part of this, I made a video about installing and running it:

There will be a few more releases like this to come as I work up towards a big public release at the end of June (10 year anniversary of the last release).

If you are a backer and didn’t know about this until just now then let me know. Also, if you have been a periodic contributor to my open source projects and are interested in a link then PM me and we can discuss it. I don’t want to dilute my backer-benefits too much but many of you have been great contributors in other ways, too, and deserve to be counted.

In the immediate short term, I need to get my open source projects into maven central which brings with it a whole tool upgrade dependency chain I’ve been dragging my feet on until I got this release out.


I decided to learn how to do networking stuff in JME, so I made a c̶r̶a̶p basic multiplayer fps shooter that works with LAN, its been fun.

Also, there was a bug before, and I thought it looked cool so here it is :slight_smile:


I spent 4 days converting all of my gradle 2.14 builds over to the latest 7.4.2 gradle. Tedious. Since now enough stuff is converted that I can work on Mythruna again, I celebrated by adding another random building type to the mix.

What’s the building way off in the distance?

Hmmm… looks rather temple-like:


On the long hiatus between the new working engine and the old public release, I got rusty with using Mythruna’s special block types… it’s starting to come back to me. Sort of like building with Lego.


Just a short bad quality video, actually two in one, showing what i am working on.

The scene is made of 401 PBR tanks and 1333 moving lights.

The top-left render shows the scene rendered with some sort of “revised” forward singlepass shading that supports unlimited lights (i mean… until the gpu freezes… that kind of unlimited…), it uses a combination of UBOs, buffer subdata updates and some other tricks to scale and shrink to fit all the the lights that are needed.

The bottom-right render shows the scene rendered with tiled deferred shading, not the common type of tiled shading since this implementation uses larger tiles and does the culling on cpu, however performances seem quite decent and, since it doesn’t use compute shaders, it can run on gl3 and gles3, so i am pretty happy with the result (for now).

On the very top of the screens you can see (if you set 720p and squint) an info bar with the data recorded by renderdoc, i don’t have an avg frametime or anything like that, but you can see the framerate count that is ~30 fps at best with forward* and ~60+ with tiled deferred. The test was recorded on an rx580.

Another thing that is not shown in the video: the env probes are rendered at runtime on the gpu pretty much instantly (for very high quality probes the workload can be distributed on multiple frames).

I will release after sorting out some last details.


Another thing that is not shown in the video: the env probes are rendered at runtime on the gpu pretty much instantly (for very high quality probes the workload can be distributed on multiple frames).

:mechanic: You are damn good mechanic here. A hero i would say. earlier 10 second probe render vs now 0.1 sec i belive, hehe.

and tile deferred doubled fps is just great. Tho using 1333 lights sounds crazy

Awaiting for JME related changes to try this out! :+1: Glad that you share info on HUB.


TANK you


Don’t get me wrong, but I think it’s April already…

ehmmmm… fixed. My bad :smiling_face_with_tear:


I’ve been working on this mechanic for my game. There’s a sort of “Radiation Visor” item that when you equip it you can barely see where you’re going, but allows to see things that would not be seen without it.

So my plan is to add some obstacles that can only be sorted by equipping the visor, also to see enemies in the dark, etc.

Here’s a video of a map I made, the player needs to cross a bridge to advance but there are some invisible “plasma beams” that would kill the player if touched, but they randomly turn off for a short time when they are safe to cross.

There’s a post processing filter that renders the GlowMap (my game doesn’t use the GlowMap otherwise) and I also reduced the resolution and limited the colors for better effect.


Resurrected my old(ish) flame shaders and integrated them into the new Mythruna engine with colored lighting values, etc…

Here is a demo of them in action:

I need to clean up the code a little bit and then I will port it to the SimFX library (with a different flame texture).


A major challenge of running jMonkeyEngine v3.5 apps on the Mac Mini G5 is living without the JME settings dialog. (The next JME release should include an alternative settings dialog that’s compatible with LWJGL v3.)

The approach I’m pursuing is to build a display-settings editor into each app, using my Acorus user-interface library. The screenshot shows an active display-settings editor in RopeDemo, one of the Minie example apps. The user is about to switch the app to fullscreen mode.


This is perfect! If possible would be really helpful if you split the view into an interface and a implementation using Acorus. This way it should be easy to plug a custom UI made with Lemur or Nifty and take advantage of the logic.


Thanks for the suggestion. I’ll keep it in mind as Acorus evolves. (It’s currently at version 0.9.13 and very unstable.)

My fork of Nifty has included a display-settings edit screen since 2019. The Acorus editor is closely based on that work.

If someone wanted to write a display-settings editor for Lemur, they could copy the the low-level functions from Acorus and build on those.

1 Like

I didn’t know you had a nifty fork, where can I find it? I’d like to try it :smiley:

1 Like

It’s not ready for general use, mainly because it depends on Acorus. Its working title is “jme3-utilities-nifty” and it’s a sub-project of the jme3-utilities project.

1 Like

Q: What brings you to Benares?
A: Testing the 3.5.2 candidate build on a Raspberry Pi 400!


It’s really great to see that, full jme3 and physics functionality, and it becomes more funny and challenging when using a custom hardware through pi4j as a jme input through RawInputListener and add it via addRawInputListener() :slight_smile:, i really did that before, but didn’t incorporate it within a jme3 RawInputListener, i think may be it will be optimized to use the input within jme update.

I hope we can optimize a PBR version for raspberries.


I’ve been working on remodeling the classic “Mythruna girl”. While I could be happier with the mesh topology, I was able to give her a basic walk and jog animation. It looks silly at faster speeds but will work until I can implement a run animation.

Click through for a quick video… I didn’t upload it to youtube, just twitter.


There is a noticeable pause at the end of each animation cycle which is some discrepancy in how Blender sees the animation and JME imports the GLTF. Worst case is that I’ll just add a JMEC script to truncate the animations by one frame during conversion.

Now that I’m reasonably confident that the mesh topology is “good enough”, I’ll spend some time creating the UV map that will work with the clothing system.


A reason could be that animation starts from keyframe 1 not 0 in Blender (which is the default in Blender). You need to move the keyframes in timeline so they start from keyframe 0.