JSME - Monkey engine with JSweet and WebGL

The initial effort to bring JME concept and java code to run directly in the browser via jsweet and other custom made candies.

Purpose: To be able to use jme concepts and toolset to create browswer game. Good things people may want to use:

  • The core functions
  • The blender workflow
  • The UI eg: Lemur, Nifty
  • Shaders
  • IDE like Netbean and Gradle

    According to personal taste I made up such priority list. The port effort also follow this list and base in jME3 core 3,2,1 stable

JSweet:


JSweet leverages TypeScript to write rich and responsive Web applications in Java through the use of JavaScript libraries and frameworks. With JSweet, Java programs are transpiled (source-to-source compiled) to TypeScript and JavaScript for being run in browsers, mobile Web views, or in Node.js.

TLDR; Java - TypeScript - JavaScript

Renderer & Bindings:
WebGL4J: (Current experimetal bindings)

Threejs:
https://github.com/cincheo/jsweet-examples-threejs

With the source code:

  • From Java. Need to clean up current jme3 code to separate needed classes and concepts that we able and going to port.
  • Generate TS source codes to target/ts folder
  • Make binding target WebGL and Threejs
  • Make examples for simple games
  • Improve SDK to easy build target for WebGL
  • Maybe Eventually introduce brand new IDE for Web builds … (will be in a separated thread)

Problems:

  • Really needs a structure changes:
  • core package codes do not have a clean separation (plugins, tools, opencl…) should be external but now tied with core
  • unused code and import everywhere :slight_smile: that make the transpiler impossible to work with default settings (should apply lint somehow)
  • For example DI, something like Dagger to provide exchange-able plugins and services

Thoughts?

1 Like

Well… in my humble opinion transpiling is not the way to go. It’s very often very tedious and comes with major limitations.
However webassembly seems to be what we should be looking into if we want JME in a browser.
There are 2 known intiatives to make that come true

and

http://teavm.org/

3 Likes

Though I do agree with you that transpiling isn’t the way to go JWebAssembly doesn’t seem ready at all yet. Meaning that we either have to wait until it is usable or go with something else in the meantime.

Also, I’m guessing that a lot of the work needs to be done either way like bindings for webgl so it may be useful to already start working on those changes and using jsweet in the meantime. That way, whenever compiling to webassembly becomes feasible a lot of the work has already been done.

Having said that, it looks like TeaVM’s webassembly part is also experimental but is also able to compile to javascript. Does anyone know how well that part works? Because going with that would probably make compiling to webassembly a lot easier once it is out of the experimental phase.

Actually the transpiling process is pretty straight forward and simple because its mostly handled by JSweet maven task. The problem is i have to modify the current code base, we did successfully create a working example with lwjgl before so I think it’s possible. For now that’s a “not so bad” solution for what we need. But of course I’m looking for alternatives such as java byte code translate to js, there are a few now:


I tested Bytecoder with great success for an AI lib but my target is to “port” JME3 concepts and reuse the toolset. I will still folow this path. Not so bad, also some fun on the way indeed!

Sorry for bumping this thread…Wanted to add a bit of new info for anyone interested. :slightly_smiling_face:

Seems recent CheerpJ 2.0 release comes with WebAssembly support too.

Another one that might catch interest in the future is GraalWasm

3 Likes

@Darkchaos has been playing around with this but I’m not sure how far he got? Maybe he can tell us more?

First I tried TeaVM and got so far that only Asset Loading and Rendering were missing but I was a bit unsatisfied with the direction the project is currently facing, so I tried to use Bytecoder, but currently compiling jme with it fails as some class libs weren’t implemented and as opposed to TeaVM, it doesn’t support passing them on your own, yet.
Waiting for the Dev on that one and then slowly and steadily progress from there

Hello, @Ali_RS

What our team did at that time is to port “JME Concepts” to the web, not the whole code I wil explain a little bit more.

  • Because we do not design JME3 at the beginning to be able to be ported or trans-piled, so definitely some forks and changes here and there to make it work…
  • High level concepts like Nodes, Controllers, States are really good. JME have this high level concept that can be reused
  • We want to utilize any other Java libs that we can transplie or any other Js libs

What we did:

  • Following in ECS approach, aka “Everything is Data”, we created another Engine Atom that can run in JME3 target, except for web.
  • Then create another runtime based in Babylonjs that run for web.
  • We also create another experimental runtime base in PixiJs that run 2d,
  • We created a Studio in JavaFX to edit the ECS data, and be able to build to crossplatform target we want to.

After match:

  • It’s a very big and ambitious project involve Java, Js, Python and cost us 2 years of development.
  • We release a few game with it, not really success. We move on! Which is sad for me personally but we surpass some challenges on the way, which is nice!
  • The project later (1 year later) transform to another kind of Editor, right now in Electron and just generate Phaserjs and Babylonjs runtime.

Recently I’ve move to US, I actually have the idea of open-sourcing this, or at least JME part, the legacy code work with JME 3.0. Tell me what you guys think about it.

3 Likes

Do not know about Bytecoder, but regarding TeaVM seems it restrict some API usages and requires some manuall code rewriting:

There are Java APIs that are impossible to implement without generating inefficient JavaScript. Some of these APIs are: reflection, resources, class loaders, and JNI. TeaVM restricts usage of these APIs. Generally, you’ll have to manually rewrite your code to fit into TeaVM constraints.

Apparently CheerpJ provides a JRE in WebAssembly and does not require any change to be made to the source code.

CheerpJ achieves this by:

  1. Covering 100% of the Java 8 language, including reflection and dynamic class generation;
  2. Providing a full Java SE runtime library;
  3. Supporting file system access (read and write), audio, printing through native browser features;
  4. Supporting Java multi-threading and HTML5 WebWorkers;
  5. Converting Java from bytecode, without requiring access to the application source code.

CheerpJ combines an AOT Java bytecode compiler with a full Java runtime in WebAssembly and JavaScript, allowing virtually any Java application to be converted to JavaScript without manual intervention.

Differently from alternative solutions, CheerpJ does not require any change to be made to the source code of the application, supports 100% of the Java language and runtime.

One thing that I could not confirm is about the Java networking support.

Edit: Note that CheerpJ free licence is only for Non-commercial use :frowning:

I am the project owner of JWebAssembly. I hope the pure JUnit test driven development to complete in 1-2 month. For continue development I search some real Java project that can be run in the browser.

I have play a little with jMonkeyEngine. Nice tool. But it seems very desktop orientated. Of course I does not understand many from the engine. But things like files or system properties make no sense in a WebAssembly environment. Do you have some work that is not such desktop orientated?

I have try to compile a simple com.jme3.app.SimpleApplication. Can be a mistake.

3 Likes

Hi @Horcrux7 :slightly_smiling_face:
I think there is a missing part that will prevent to run it on the browser, and that’s the rendering backend. Currently, we do not have a WebGL backend implemented for JME.

Are there an y plans for WebGL in the future?

Do not know.

As far as I am aware there are no plans for the core developers to create a WebGL renderer. Having said that there is nothing stopping someone else creating one.

In my opinion there’s nothing wrong with ThreeJs - it’s designed from the ground up to be web-based.

It should be pretty easy to implement a webgl renderer, if the transpiler allows calls to webgl (it is GL ES).

The previous comments in this thread suggested that it was already started.

PS: For a new implementation I think WebGPU is better as WebGL.

This is totally doable if you use threejs as a frontend engine,
At present, Threejs can implement a port of recast-detour for navmesh,
It can also implement Bullet physics (Ammo.js)
The engine renders pretty fast, its perks are awesome and broad for this purpose

Here are some of my works during my lazy period done with threejs, great performance also!

https://micicle.glitch.me/

https://waverider404.github.io/voom/