Next release of the Engine

Development
21

Summarizing the input so far…

Desired features and fixes:

  • supply missing javadoc (see for instance PR 1618)
  • create UML diagrams explaining how the Engine works
  • solve right-to-left line wrap issue (issue 1158)
  • double-precision scene graph (see recent discussion at issue 1384)
  • update wiki to cover the new animation system
  • enhance the animation API (issue 1566)
  • enhance the Camera API (issue 1538)
  • provide access to glscissors (no recent issue but see the 5-year-old discussion at PR 267)
  • better filters (details/specifics?)
  • better render pipeline (details/specifics?)
  • improve the animation system (details/specifics?)
  • support textures compressed using BC7 (issue 1619)

Several people offered to help with testing. (Thank you!)

Other suggestions:

  • drop LWJGL v2
  • bug bounties

What’s missing so far:

  • No one mentioned wanting a v3.4.1 Engine release.
  • No one offered to develop code or work on documentation. (Though to be fair, I’m seeing a burst of activity on 1158, 1618, and 1619.)
6 Likes
22

That’s an interesting question for me actually. I’ve started getting used to work, but even if I have time, it’s mostly the week-ends and there I’d probably have to keep up with the SDK, which actually would require substantial cuts in features to sustain. I feel like it would be more fun working on the engine itself, but well…

Nevertheless, I’d have a few suggestions:

  • Platform support. See #1611 for iOS, a few Android API improvements (not specifying the main class name as a string), a cross-platform (android and desktop) gradle template. Going to the web, either with transpilers like Bytecoder (#454) or using WebAssembly maybe together with some embeddable JVM.
  • Improvements of the Gradle SDK Template as it apparently seems broken, see the above as well for that
  • CI/Tests improvements, as has been seen in #1591 recently, don’t forget I had the jme3-testing project, that interestingly seems broken due to some framebuffer format stuff
  • +1 on the Animation System, a feature version bump doesn’t need to maintain compat
  • Promotional projects. We wanted to do a game jam together, but it never happened because of a lack of concepts/ideas. The basics were having a “stoppable” and lookable roller coaster with rooms showcasing specific features. Additionally we could also at least bring all our tests into an Android App that is available on the Play Store, so that we can easily test those.
  • Everything from GSoC 2020 is still up for mentoring from my side, “just” not paid by google.

For the SDK I still need to request to keep lwjgl2, though probably another topic is to get my lwjgl2 fork to build, in order for it to work on more recent Ubuntu Systems with more recent JVM Versions. Unfortunately it uses a mixture of maven and awt and javascript-scripting-in-awt depending on the old jvm-javascript-engine-syntax.

Furthermore I probably need to cut the embedded blender, which will both reduce our size by a gigantic part, as well as because the synergies of importing fbx by going fbx->blend->j3o won’t work anymore, unless we’re rewriting them to be fbx->blend->gltf->j3o, which probably fails because you’d need to setup the materials in blender.
And even if so, you can probably link your existing installation.

Another fun will be that pack200 is deprecated/removed with the most recent jvms iirc, so the bundle size goes up anyway.

There’s probably a lot more I forgot about, such as the update center on github and the build in general, but we just lack the manpower anyway.

Oh and there’s my WIP roadblock on the software store because I couldn’t get jQuery to be globally available and a few other minorities.

Render pipeline improvements would come from the use cases that we build with the showcase project, in my opinion.

And besides polling, I guess we have to be happy with having someone do anything at all.

5 Likes
23

As I have proposed before, the fix for this is to remove the String reference & use an instance setter, that what I have done for JmeSurfaceView.

I think this is manageable, I will try to do it, it will involve pure gradle work.

As for the Mobile Demos with some sophisticated Ui/Ux, I think I can do this, if I can iterate over the jme3-test package classes, I can create a gl renderer for a selected jme class from a list using JmeSurfaceView easily, and we can have a side transparent command line to log events & catch exceptions while game is running…besides I have my own google developer acc.

2 Likes
24

If version 3.4.1 were released tomorrow, also in this case I would be available to update my projects and to provide any feedback. I saw that you have done an excellent job of cleaning and optimizing the code and that some interesting things have been reported and fixed by the community. IMO the release of small and frequent updates would be a good advertisement for the engine while we wait for version 3.5.0 :smiley:

4 Likes
25

A few tought from my side, even if i have currently no time at all, but i hope to get some free time back when private stuff has settled a bit.

Since Momoko and Nehon left, there seems nobody is working on core rendering features anymore. Not to say that all the work going on is less important, but simply looking at the gfx rendering i would not know a large feature addition after PBR/Animation.

I am not sure how deep changes are possible without breaking mostly all existing projects. Yes, the pipeline is flexible enough to let me change it completely, but adding new features as drop in replacement is quite hard.

As example: Tessellation. While it is possible, supported to have any kind of tess. shaders, it is not possible to add that features to the default materials. There would have to be made changes to the MaterialDefinition definition, allowing for “smart” technique selection. (I.E: If mesh.type==Patches && Mesh.PatchCount==3 use tessellation technique)

Adding such features to the core is such a big project that everyone wanting tess shaders did there own thing. But for the other engine users there is no progress.

Same goes for other lighting techniques. There where at least 3 different deferred implementations, but not a single one was compatible with the default engine. So i guess all three died and there is still no implementation usable by the large audience.

That said i am also not sure how this problem should be tackeld.

4 Likes
26

Sorry. I am not sure about this. Is it GLTF loader problem with transparency? If it is, can it be fixed? Previously it works with blender exported with alpha clip (with proper shading).

Edit: nevermind. I can add transparency later. edit again: I check again seems it’s okay but maud can’t handle it.

27

@melod:

Sorry, I’m unsure what glTF loader problem you’re referring to. Please provide more details.

To request Maud enhancements, please create a new topic or open an issue at GitHub or send me a private message.

28

the release of small and frequent updates would be a good advertisement for the engine

It would be wonderful to have some positive news out of JMonkeyEngine!

In order to justify a v3.4.1 Engine release, we’d need to identify one or more low-risk bugfixes in the “master” branch that aren’t in v3.4.0 . A quick search turned up 3 candidates:

To me, all 3 seem like very minor bugs—corner cases or easily worked around. Am I mistaken? Does anyone know of other bugfixes that would be candidates for v3.4.1 ?

3 Likes
29

I thing it’s maud. Not gltf loader.

30

Are there specific filters you wand added or updated?
Are there specific improvements you want made to the animation system?

31

Paying developers raises many issues. It tends to demoralize/devalue everyone who contributes but doesn’t get paid. It encourages the attitude that “paid staff are responsible for that stuff, not me”.

The JME project has plenty of cash, and I’m not ruling out bug bounties, but it’s not something I’m eager to try.

Paying contributors seems to be a hot topic currently at the Open Source Collective. It’s interesting to read about the experience of other projects. See, for instance, https://opencollective.com/opensource/updates/open-source-collectives-first-community-call.

2 Likes
32

This would be my top priority, too, if I thought someone else would do the work!

33

I very much agree, to pay a developer their actual day rate to write code would burn through the cash very quickly. I wonder if there’s a middle ground of sending contributors jMonkey merchandise

1 Like
34

What about AWTLoader improvement (#1613)?

Edit: and this (#1614)

3 Likes
35

1614 is a very good catch! I missed it because I was only looking at what’s currently committed to master.

1613, as I understand it, is purely a performance enhancement—not what I think of as a bug fix, but I suppose it could be included.

3 Likes
36

Also #1158 (It’s WIP)

1 Like
37

It occurs to me that 1614 provides a good argument for releasing a 3.5-alpha before 3.4.1—the reasoning being that, since we don’t have a directed test for 1614, it will need broad exposure before we can be confident it doesn’t break applications.

2 Likes
38

Other features we might consider dropping:

  • the old animation system
  • virtual reality
  • Nifty GUI
  • JBullet
  • FBX loader

Also, I’m looking forward to additional details on why we should drop LWJGL2 support.

3 Likes
39

The new animation system doesn’t still support all the things the old one did. Namely the LoopMode can’t be implemented fully. That is a major issue in our project. I think this is still true. The PR trying to address this was never merged (Added feature request #1019 by Ali-RS · Pull Request #1038 · jMonkeyEngine/jmonkeyengine · GitHub).

2 Likes
40

If you think that will ease the API usage I can re-open that PR if someone is willing to review it. :slightly_smiling_face:

1 Like