Is there a plan to make Minie part of JME instead of add on. Fully integrate it into JME and replace the JME docs to reflect Minie instead of JBullet.
Just wondering.
1 Like
I did suggest that (in this Forum) back in October, but I didn’t observe any enthusiasm for the idea. So currently there’s no plan for this AFAIK.
Too bad. Minie is better than the JBullet and it is the only Physics being updated. Its weird like the Particle Emitter system. JME is stuck with something that it outdated, has bugs and there is a good replacement but not part of JME.
1 Like
Yes, it’s unfortunate. Personally, I believe our project has bigger worries than JBullet versus Minie. We’re also in a weird state regarding Nifty versus Lemur, community management, the Wiki, the SDK, Vulkan, LWJGL v3, the Store, and a few other things.
And all that weirdness is, I think, symptomatic of limited resources. The issues getting resolved are exactly the ones that our current volunteers are motivated and able to solve. The unresolved issues are … everything else. And that’s a lot.
That is a problem. Not enough people willing to make those things a standard, like you said limitation on what can be done.
1 Like
I think the current trend is that everything should be a separate project. Every area, like physics etc. So that they can have separate release schedules and do not burden the core project (maintainability). This is not a opinion, just how I understood things.
4 Likes
Yes, that’s right. If I fix something in Lemur then I can release it the next day if I want to. If I fix something in JME then it might be a year or more before most people get it.
And that was true even when the active team was larger. “I fixed this thing in X can we make a new release?” “Wait, there was this other thing we wanted to fix in Y and Z… oh, and we’re waiting on A, B, C…”
Even JME could benefit from separate release cycles for its parts.
3 Likes
Flexible releases are a big advantage of the “everything should be a separate project” philosophy.
Another advantage is clear ownership: there’s no doubt who’s responsible for Lemur or Minie, whereas jme3-jbullet has no owner (5 open issues dating back to 2018) and it’s unclear who should be setting the direction for jme3-android and jme3-vr.
On the other hand, the current situation is confusing for newcomers. New people tend to start with jme3-jbullet and jme3-nifty thinking they must be best because they’re “official” and are highlighted in the Wiki.
There’s also risk of “version hell” if the core API were ever to change rapidly. In which case, someone might have to dig to find, say, a version of jme3-core that’s compatible with the latest Lemur, Minie, and ParticleMonkey. (Not saying that’s the case currently, but it could happen.)
With VR I’ve been trying to make “small, core, enabling code” within jme3-vr and then “fancy, useful, big” things within Tamarin (or competing libraries I guess). That feels like a good thing, a common stable base we can all target but that is manageably small. I guess an equivalent of that would be that many of the particle libraries want to use the Particle.j3md material, so maybe that’s part of “small, core, enabling” but the actual emitters aren’t?
But to make that work you’re right that it needs to be easy to discover the non official things. That was why I was hoping to present “menus of options” within jme Initialiser to make them more discoverable (I was waiting for a VR template I didn’t feel ashamed of before trying to move jme Initialiser forwards, which I now have, yay!)
But it does feel like “unofficialling” the things we don’t like any more would trick people less. Maybe a first step in that direction is to stop calling them “JME” even if they technically are under that group id and demoting them to equivalent to our other contributions?
1 Like
Maybe a first step in that direction is to stop calling them “JME” even if they technically are under that group id and demoting them to equivalent to our other contributions?
I don’t believe the “org.jmonkeyengine” groupId means much to newcomers. I think the confusion results primarily from Wiki and to a lesser extent from the SDK, the Engine repo, and jme3-examples.
Renaming is a possibility. If we were to rename “jme3-jbullet” and “jme3-nifty”, what should we call them?
Within the initialiser I’ve just called them Nifty and JBullet. I suppose that’s technically not 100% true, as they are those things plus a JME wrapping.
1 Like
Maybe what should happen is something like LWJGL. You can download what you want and it packs it together so when some download it, they have everything they want.
Now, have of the stuff you have NO CLUE they are out there, you have to find them. Then download SOURCE CODE compile and get them over to your libraries so you can program.
HUGE hassle and now sure what is all good or not. So many of them use different version of gradle, you go to github and shows their 3+ old since last date. Then as NEWBIE you are not sure will they work with current JME or not. So many questions are left in the air for NEWBIES. It make a person think twice about JME.
This way you can keep them separate but offer a bundle to put them together compiled for the user to be able to get going.
Just if you want thoughts about what is missing.
richtea has a good idea and start.
2 Likes
Then download SOURCE CODE compile and get them over to your libraries so you can program.
It shouldn’t be necessary to download and compile source code for JME add-ons! Every add-on library should release Maven artifacts, preferably to Maven Central.
I realize publishing to Maven Central looks difficult, particularly if you’ve never done it before, but I now have a year’s worth of experience and am happy to assist JME-related projects that want to publish there.
3 Likes
well i agree with sgold here. Always belive that JME is more for programmers that use artifacts. So i would not see difference if there will be sgold repo artifact or JME repo artifact. (its just a name)
I agree that Minie should be standard tho, but would need just promote it somehow.
1 Like