Plugin-Based JME DevKit

[janvonpichowski]

I watched your video above and noticed that there is some lag from selecting the car model in the file chooser until it is added to the scene. I think it is mandatory to have some kind of progress bar or symbol for beeing busy, like you could find in matlab. Otherwise the user might think that the application has stopped. I would suggest adding it to the base of your system because most of the plugins which do heavy work would need it. Maybe with some option to load in an addtional thread to keep the gui responsible.

I think such a devkit could become difficult very fast when there is more than “only” a window manager. Maybe it is good to think beforehand about additional needed interfaces like thread handling, resource handling, etc. I don’t say that you have to implement everything. Then we would have a complicated system like NetBeans Platform and all of the issues which comes with it. Until now it looks very promising and I am eager to try it out. Well done so far!

There is one more question. Since you are doing everything with the jME toolset. Would it be possible to start the devkit in a running game. Or are there any troubles?

Thnks for your work.

[jayfella]

@janvonpichowski

I think such a devkit could become difficult very fast when there is more than “only” a window manager.

There is (and will be) more than that. I want to provide the basic functionality and not a lot more specifically because I don’t want to over-complicate the process for the user. You can create windows and add menu items. Which means you can control the GUI. It doesn’t really need to be more complicated than that. The level of complication thereafter is based purely on how complicated your plugin is. If you want multi-threading - write it yourself. I can’t hold your hand - and neither should I - because that makes the plugin system way too complex. I can’t accomodate for every single situation - but you - the plugin developer can.

Having said that - simple things like async asset loading takes 5 minutes to implement and I’ll more than likely provide that. I’d like to also provide some kind of scene treeView - and all the other basic elements like transform manipulation.

The end result here is avoiding having 100 different editors people have made - and to unify it to a single app with multiple plugins. Ideally what I want is just to provide them with an instance of Application and give them free reign to make their thing. In reality if it is going to look good - I need to provide a GUI for them to work with - and that’s all. I do not want to force a workflow onto people, or a threading pattern. Writing a plugin is simply a matter of an entry point (onLoad, onSelected) to begin your venture, and an exit point (onUnSelected) to clean up after yourself.

The GUI will just make things neater - as shown below, so every plugin has the same look and feel, and it makes development a lot quicker.

[janvonpichowski]

Okay thanks for your long explanation. This makes it more clear to me what the point of your devkit is. Of course you are right that it isn’t to difficult to write a loading window. And I think it is a good way to move the work and freedom to the plugin developer.

[QSDragon]

Nice job with this @jayfella. This is a problem I face with almost every game I make and I’ve done very similar things to this in the past, but never fleshed out enough to really port between projects. I’m definately looking forward to this!

[xuan]

As someone that’s making his own niche editor, what do I gain by using this?
Creating a new app and adding a state is trivial compared to having to learn another API and managing the lifecycle of building the plugin and installing in another application instead of just running my application.

[jayfella]

If you’re creating something simple or related specifically to you, there’s probably no need to write a plugin. I’d probably do the same.

If you’re creating something more complex, for example building a vehicle from a model by picking wheels, chassis, etc (maybe you’re making a vehicle game and have to import a ton of vehicles) or a terrain editor (finer details are a nightmare without a visual editor), or if you want to use some of the built in functions like transform manipulators, scene trees and property editors - it’s probably better and quicker to write a plugin. In addition, by publishing that plugin on git - If it’s useful it will also get improved by the community, too.

One of the biggest issues a lot of people have with JME is a lack of GUI tools. Opinion is also heavily divided on a IDE to use - and varies from year to year. Today it’s IntelliJ, tomorrow it’s something else.

By separating the IDE away it lets you use whatever IDE you want - much like unity and UE4 does. So we aren’t prone to seasonal IDE popularity anymore.

By having a set of plugins for terrain editing, model importing, vehicle creation, and all the other possible plugins - it immediately makes JME more accessible and easier to work with.

[jayfella]

I’ve created a gradle JmeDevKit plugin to make creating plugins as easy as possible. Your build.gradle file should be as simple as this:

plugins {
    id "com.jayfella.jme-devkit" version "0.0.2"
}

group 'com.myplugin'
version '1.0.0'

jmonkey {
    // manually select a version, else the latest release is chosen.
    // version = "3.2.2-stable"
}

dependencies {

    // reference the devkit API
    compileOnly devKitApi()

    // optional if your plugin directly uses any jme-core related classes.
    compileOnly jmeCore()

    // optional if your plugin uses a GUI.
    compileOnly lemur()

    // and maybe you use some extensions of lemur, too.
    compileOnly lemurProps()
    compileOnly lemurProto()

    // I depend on this plugin
    compileOnly "com.jayfella:EditorCamera:1.0.0"
    
    // I need this library included in my plugin JAR
    implementation removeIncludedTransients("com.simsilica", "jmec", "1.2.0-SNAPSHOT")
    
}

configurations {
    releaseJar.extendsFrom implementation
}

jar {
    from configurations.releaseJar.collect { it.isDirectory() ? it : zipTree(it) }
}

So the main reason this is needed is because a lot of things people make include the JME libraries with them - and they’re not required for a plugin. It also means when the plugin is built using the gradlew jar task - the size of the plugin will be quite large because it contains the JME libraries.

For example if I use lemur as a dependency - it depends on jme3-core - and I’ll be dragging that everywhere with me in my plugin - and my plugin size will reflect that too.

In the example above, we compileOnly on things that we just want to reference. The devkit already provides all JME libraries and Lemur. The devkit gradle plugin automatically removes any transient dependencies it already provides for you.

In a similar sense, the removeIncludedTransients(group, module, version) helper method also strips out any dependencies that the API provides for you so you don’t have to.

Hopefully this should mean that making plugins is a lot easier and goes a long way in to reducing the complexity of understanding transient dependencies and creating plugins.

Again - this is obviously a very early outline right now. If you can think of any suggestions - please do chime in

I’m going to upload the actual devkit and API projects to github in a week or two - mainly so I can begin to work with live releases instead of mavenLocal. When that time comes it will let people create and use the system - albeit alpha stage - meaning the API will more than likely change over time as the project moves onto a more stable official release.

As a side note - don’t forget you can support JME development via patreon!

Jayfella & JmonkeyEngine Developers is creating JmonkeyEngine | Patreon

[raistm]

Ha, I just noticed you’re on patreon so I’m sorry for a such a delayed contribution

[jayfella]

Thank you for your support! We lost a sponsor this month so it’s all the more needed. Thanks again.

[jayfella]

Just a heads up on what’s happening.

Some of the code I was using was under a GPL license - and I don’t think any of us would see that as an ideal - so I’ve had to redo a lot of code which is under the much more permissive MIT license. In a nutshell it just means that you will not be forced into publishing any source code.

[jayfella]

Another short newsflash. I’ve re-written the plugin and event system - so I can license them as BSD-3 and resume work on the devkit.

[jayfella]

Slowly but surely each area of the DevKit is making its way to github.

I wanted to make sure each area is not just DevKit specific. Users should be able to use the plugin system, event system, theming system, menubar, etc… in their own game, too, if they wish. Aside from the fact that this is of benefit to the average JME user (more libs = awesome) but it also increases the likelihood that bugs will be found and reported. It’s also a much easier task to maintain such a large project by segregating each area in its own eco-system. If all of these seperate libraries were thrown into a single project - it would be intimidating at the very least to even attempt to work with.

Libraries

All of the individual projects below are combined into a single application called JmeDevKit. I don’t mind telling you it has taken me some time to organize everything.

• property-inspector
  In a nutshell it reads a class and takes getters/setters or fields and creates JME GUI objects to edit them. For example it lets you edit a Vector3f or a ColorRGBA value of a class with a GUI control.

• lemur-themer
  Lets you create, edit, load and save themes for the Lemur framework.

• lemur-menubar
  A horizontal and vertical menu bar implementation using Lemur.

• lemur-window
  A window system using Lemur

• plugin-manager
  A runtime plugin system. Plugins are loaded from a directory at runtime. The great thing about this is anyone can use this. It is not DevKit specific.

• event-manager
  Allows the user to create and fire events. Fully thread-safe and again - not DevKit specific. If you’ve ever created event listeners in your game you might want to take a look at this.

Plugins

To start the whole “how do I make a plugin” ecosystem off I’ve created a few plugins.

• EditorCamera
  A camera movement system similar to Unity/UE4.

• Model Importer
  Import GLTF models and view them.

• Lemur Theme Editor
  A GUI extension for Lemur-Themer in plugin form. Basically Lemur-Themer-Editor in a plugin.

• Scene Tools
  A scene tree viewer and inspector.

• Property Inspector
  Provides a window with the properties of a given object.

What this all means is that things are moving ever closer to a release. Hopefully in the next week or so it will be available to use!

[jayfella]

Just an update to the devkit situation.

I’ve been doing a lot of thinking on the situation; looking at the previous attempts (jmonkeybuilder, spix, my own attempts, the official SDK, the list goes on) and what I’m actually trying to do.

I think In my journey of continual failure to create something I’d even use myself - I’ve managed to stumble on something that might just work.

I’ve written a JavaFX based app that embeds JME, and I’ve started simple, covering the first steps one takes when they look for a devkit. Importing models. Viewing models. Basic scene manipulation.

One of the other key issues is getting people to go through the whole process of getting the user to download and use it. So instead I’ve written a Gradle plugin that adds a new task “runSdk”. Just add the plugin to your Gradle build script and run the task to use the SDK.

@pspeed would be awesome if you could publish jmec on jcenter so I can get rid of that maven dependency.

plugins {
    id "com.jayfella.jme-devkit" version "0.0.6"
}

repositories() {
    // jmec doesn't seem to be available on jcenter()
    maven { url  "https://dl.bintray.com/simsilica/Sim-tools" }
}

You will be presented with a new runSdk task to start the devkit. And to get rid of the devkit, just remove the plugin from your project.

Currently you can only import models, view models, save scenes, add lights, shapes, etc… Not a great deal, but it’s the beginning of something I hope catches on. There are also debug lights you can quickly add, and probably a few things I’ve forgotten. It’s very much a working prototype.

Please do let me know if you like the idea of the devkit as a gradle plugin.

[danielp]

@jayfella

Please do let me know if you like the idea of the devkit as a gradle plugin.

I think this is a fantastic idea. Dependency management tools are great at downloading and keeping artifacts up to date, and they’re also great at integrating into developers’ workflows. Gradle in particular is often used to run a number of development tools that are outside of a standard compile-package-distribute workflow - things like code generators, documentation generators, etc. I think this provides a fantastic starting point for running the devkit, and I think you could expand on this in the future to provide even deeper integration with the development process (like having Gradle pass in paths to work with assets in several different directories at once, etc.).

[pspeed]

@jayfella

@pspeed would be awesome if you could publish jmec on jcenter so I can get rid of that maven dependency

I’ve submitted the request. Always meant for it to be on jcenter but I set my other projects up so long ago that I forgot it was a separate step.

Edit: looks like it’s up now unless I messed something up.

[jayfella]

I think it was actually Paul’s idea to run it as a Gradle task, or at least provide the ability to have a smaller model import version as a gradle task.

@danielp

think you could expand on this in the future to provide even deeper integration with the development process (like having Gradle pass in paths to work with assets i

It does do that already for the asset root directory. It also stores per-project settings in a devkit folder - and maybe a global settings in the home dir in the future.

Has anyone actually tried it? Does it launch ok? Any issues?

I have a lot of things I can add to it relatively rapidly already, but I’m hesitant to invest time in something that’s going to end up on the already large pile or carcasses that are SDKs if it’s of no use.

[jayfella]

@pspeed

looks like it’s up now unless I messed something up.

It seems fine. Much appreciated.

So now one just needs to add the plugin and run the runSdk task.

plugins {
    id "com.jayfella.jme-devkit" version "0.0.6"
}

[sgold]

@jayfella

Has anyone actually tried it? Does it launch ok? Any issues?

I tried adding v0.0.6 of the devkit to a project of mine and got the following error:

org.gradle.tooling.BuildException: Could not run build action using Gradle distribution 'https://services.gradle.org/distributions/gradle-6.5-bin.zip'.

…

Caused by: java.lang.UnsupportedClassVersionError: com/jayfella/devkit/gradle/JmeDevKitGradlePlugin has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Could you rebuild it for Java 8, please?

[jayfella]

Hm. It uses javafx-11. Jfx got separated after Java 8, but I’m not sure if the api is similar enough to just switch to java-8 - I’ll have a try.

[jayfella]

Ok. I think I’ve managed to get this to work on java 8 and above. I’ve only tested it on Java 8 and 11. I’m quite certain 11+ should work, but I have no idea about 9 and 10. It should also work properly on win/nix/mac as far as I am aware (javafx has specific dependencies for each OS).

plugins {
    id "com.jayfella.jme-devkit" version "0.0.10"
}

run the task runSdk.

@sgold (and anyone else) please give it a try and let me know how it goes.