Let’s discuss jMonkeyEngine 3.4

Development
1
  • Recent discussion didn’t turn up any bugfixes suitable for a v3.3.3 release of the Engine.
  • As far as I know, the big feature (Vulcan support) that would define JME4 isn’t getting any serious attention.
  • At least a couple folks are using JME’s master branch for application development.

Based on these observations, we should consider the possibility of a JMonkeyEngine v3.4 release. The usual questions arise:

  1. Who might be willing to manage such a release?
  2. What features/changes/fixes should be in it (that aren’t already in master)?
7 Likes
2

Is ARM support (for raspberry pi for example, not android) a good candidate?

1 Like
3

It’s a good candidate if we have someone with an RPI actively working on the release. Otherwise, no.

1 Like
4

What is it that has been added past 3.3?
From what I remember we’re far from 3.4 as we don’t have any major features or contributors for that features, yet.

1 Like
5

“Major features” is not necessarily a requirement if there are fixes that folks want in a release but are not able to go into 3.3.

Version numbers are free. We need not hold up momentum for fear of running out of them.

That being said, it’s always nice if a version bump has some new hotness to go with it.

4 Likes
6

The rpi 3 and 4 work fine with the engine already. It just needs the required external dependencies (non-JME).

1 Like
7

I haven’t reviewed all the commits, but I believe @Darkchaos is correct that no major features have been added since the v3.3 branch.

I also agree with @pspeed that version numbers are free and major features aren’t a requirement for dot releases.

However, the various v3.3 releases ate up a ton of my time, not just to create/test/publish the builds themselves but also to maintain 2 versions of Minie and my other public libraries during the 9-month transition. Perhaps that won’t be necessary with v3.4; I don’t know. Releases also create work for those who maintain the SDK, the documentation, and so on.

So unless there’s enthusiasm for v3.4, I suggest waiting … until there is.

2 Likes
8

Nope. you can run jme engine, true, but it runs in OPEN GL mode, NOT in Open GLES mode.

9

I’ve created milestones at GitHub for “v3.4.0” and “JCenter going down” so we can begin sorting and prioritizing Engine issues and PRs for the next release.

While the v3.4.0 milestone currently has no target date, this action will doubtless create some expectation of an actual release with that designation. Now is the time for those who care about the project to step up and volunteer:

  • to update the documentation as needed
  • to act as alpha testers
  • to resolve issues and review open pull requests
  • to update the SDK as needed
  • to develop appropriate new features
  • to help publicize the release, when it’s ready
8 Likes
10

v3.4 isn’t something I can do all by myself. That’s why I asked for volunteers. I’m still seeking volunteers.

P.S.: Liking a post doesn’t count as volunteering to help.

2 Likes
11

I can help with publicizing, alpha testing (I can at least test existing footprint, and maybe some new features if I don’t have to expand our jME footprint too much to make use of new features), & PR reviews.

2 Likes
12

I’m ready to volunteer. Is there a place where I can see what needs to be done and see if I can contribute? I’ll check for the v3.4.0 milestone at github.
EDIT: I see the milstone here:

2 Likes
13

Thanks. Planning should take place here, in the “Development” section of the JMonkeyEngine Forum.

14

I can hopefully help with some of these

  • to act as alpha testers

I can certainly plug it in to the projects I have and kick the tyres.

  • to resolve issues and review open pull requests

Probably nothing too “deep”, and certainly nothing shader-y but happy to help where I can.

2 Likes
15

I am not so sure if I can really do something here , but let me try , I think jme3-jbullet the last time was not working , I will try reproducing the problem to find a fix , but unfortunately currently I am constrained to my exams , so 2-3 other weeks & I will be free.

I can do alpha-testing on RPI .

2 Likes
16

You guys are really great, I really want to participate in it and carry out long-term maintenance, but I am really busy at the moment. I really want to modify the graphics rendering architecture of jme to support multiple rendering paths, and can specify the rendering path to be used from the material definition, such as using Forward or DeferredPath.

2 Likes
17

I’d love to see support for multiple rendering paths in JME. Unless we have something to test soon (next 3 weeks) I think that feature should appear in version 3.5, not 3.4.

Still looking for someone to update the documentation. I don’t want to issue another release with out-of-date documentation. It’s unkind to our users, and it places unnecessary load on the troubleshooters here at the Forum.

4 Likes
18

I don’t see any documentation issues in the milestone, unless you mean the one self assigned to you @sgold.

Is it just generally making sure wiki pages are up to date and work in the current master?

2 Likes
19

The milestone at GitHub is still a work in progress.

I’ll take care of issue 1388. (It’s fairly simple.) I’ll also create a change log for the release and post that to GitHub.

But documentation also includes the website and wiki, and those will surely need updating. For instance, I still can’t find any mention of light probes in the wIki. And the wiki’s instructions for importing models from MakeHuman are years out of date. I’d also like to see issue 96 closed. Furthermore, jme3-blender and jme-jogl will be gone from the Engine as of v3.4; the website and wiki should reflect that.

And that’s just what I know about. A careful review of the website and wiki might uncover more issues.

If we remove jme3-bullet and/or jme3-jbullet from the Engine, the website and wiki should reflect that.

And finally, if there’s no SDK v3.4, then the website and wiki should reflect that as well. (I certainly hope there will be an SDK v3.4, but nobody has volunteered yet.)

5 Likes
20

What about Nifty GuI , won’t we change that(we arenot going to remove it , but we must mention others) , you have now Lemur & javaFX on PCs & Lemur works on android too , but also you have Android views on android & it works fine without performance drop & I have proved that ,

notice that : anyone new to the engine have asked that question → How to create a game menu , pause menu

Besides , Some topics like how to make vegetations need to be provided with links to git repos , as well.

2 Likes