That’s encouraging news, @Ali_RS.
Would anyone object to releasing v3.3.0-alpha1 out of master right now — with an appropriate edit to the jmeVersionTag in the gradle.properties?
4 Likes
I am all for it!
I think that would be great!
You understand what this means, right?
This would be a non-production release, for development and testing only, not intended to be used in any product. A release that’s largely untested, without complete/reliable documentation, and without SDK support. Vital features may be missing. The feature-set, API, and serialization format might change drastically before the next release, if there is one.
1 Like
Oh, of course… I’d hope anybody would be expecting as much out of anything tagged alpha1. 
I think it’s a good idea so that the changes in master start getting used by more of the folks who don’t pull/build regularly themselves (which I’m assuming is most) - which will likely result in more activity towards a final stable release.
1 Like
In my opinion test cases should be made for the new features just like every other feature.
I feel like attempts should be made to ensure things work as intended - or work at all.
I don’t think documentation should “stop” a release per se, but does anyone even know how this new animation stuff works?
If someone asks a question about it, is it just a resounding “we don’t know”?
2 Likes
Well, there are some relevant tests in jme3-examples:
- TestOgreConvert
- TestGltfLoading
- TestAnimMigration
- TestAnimMorphSerialization
- TestArmature
- TestBaseAnimSerialization
- TestHWSkinning
- TestModelExportingCloning
- TestMorph
- TestLodGeneration
The support issue may be more problematic. I can only speak for myself, but right now, I’d have to answer “I don’t know” to just about any question about MonkAnim.
While “MonkAnim” is catchy, I’d like to point out that this is “the new animation system” that just happened to be developed on the MonkAnim branch… as the idea behind MonkAnim was essentially abandoned. Someone might still pick up that idea someday and it would be cool if they could still call it MonkAnim.
…but continuing to call it “MonkAnim”, it would be like if we refactored the Material system on the PBR branch and so called the new Material system “PBR”. But I digress.
JME has a new animation system. In code, it is better documented than the original animation system by far. It lacks tutorials, etc… That kind of requires users.
Also note that I think the average incubation of a JME alpha is like 2 years with around 4 alphas. So if we start getting it in the hands of folks then I think we are more likely to see these things evolve than if we never do anything with it.
5 Likes
Also also note: there are not that many people who understand the old animation system either. Most responses to questions are based on “accepted lore” at this point. We just need to develop lore about the new system.
2 Likes
I have a couple of philosophical questions about jme development. What really is the divide between core and addons with jme? Is there a reason certain popular addons don’t get merged into core? I know some of it is a maintenance thing but there are a bunch of addons out there that are far better than what exists in core such as particle systems (and I would argue lemur). I know jmonkey tries not to be very opinionated with things but I would argue pspeed’s entity system deserves a spot there too. I know for spoxel I spent a lot of time just getting a framework together so I wasted a lot of time working on an “engine” as apposed to my game.
Is there any thought about long term targets for jmonkey? Things like vulcan support come to mind.
I’m just finishing up the initial release of Spoxel so i’m going to have some time I’d like to spend on jMonkey going forward 
2 Likes
JME: releases approximately every 4 years on average.
Lemur: releases every few months.
Zay-ES: releases as often as needed.
That’s really the issue with integration. Everything is way more agile without integration… both JME and the other things.
And in modern build tools, grabbing these other things is just a matter of adding the right dependency.
Could they be advertised better? That’s probably true. I don’t know what the answer is there.
Edit: all that being said, when the SDK was separated from the core engine it did open up the possibility that the SDK could be an integration point for a lot of these external libs just by including them by default when bundling.
1 Like
That makes sense. JME is so decentralized it makes it hard to have a consistent message compared to something like unity which seems like a sticking point a lot of new users hit.
That is a good point about the sdk. I wonder if there is a better way to tie that together there or maybe with one of the project creation utilities that have been posted. I had to switch away from the sdk for coding for a variety of reasons but I still use it for assets.
1 Like
Yeah, I haven’t used the SDK in probably three years… even for testing. These Windows 7 machines don’t even have any version of it installed at all.
I think there are at least two project creation tools out there by now? I think Nehon made one that used node.js or something… which makes it a bit of a non-starter for me because I have nothing but trouble trying to get node.js apps to work sometimes.
Gradle has the ability to run a build file from a URL which I thought might be kind of neat for a project configurator but would require that gradle already be installed.
Something like libgdx has would be neat. Just a jar you run.
I am using netbeans 10 and 8.1 for most of my work. But on small projects I use the sdk mostly because I like the theme and I am too lazy to figure out how to get it on my other netbeans installs. 
SDK(or any other tool-kit) is important because otherwise material editing/j3o conversion/model quick preview/shader preview/and much more would be pain.
i use gradle, and i split projects into 2 pieces: assets project(ant - SDK working on it) and code(gradle).
if i would not have sdk, then using command line for this things would be pain so i would seek new toolkit or create one, because its really required.
Its also about new developers. SDK help them understand engine more quickly.(not the code, but logic of engine). Recently there was topic about new members, and was said that someone must become person we need. but to become this person, he or she must first join engine community, but to help, SDK, tutorials, tests and documentation are required, otherwise person like this will just not join something that is new user unfriendly. Thats just my opinion.
We aren’t arguing against the SDK.
We’re trying to come up with a way to make it easier for folks to start and find the nice add-ons that aren’t using the SDK. The SDK already has an advantage here because it can bundle all kinds of stuff. One could even imagine a Lemur or Zay-ES game template or whatever with libraries preconfigured.
Those not using the SDK can never have that and so it would be nice to have a project configurator tool of some kind.
1 Like
i never had problem finding “plugin”(i understand you mean any jar project here), forum topics + github repos were enough for me to find what need.
but what i managed to observe was that many of this plugins were dropped/abandoned for some reasons. (yes even i dont upgraded some of my, shame me).
So more important would be making some plugins centralization to people can take over abandoned plugins or help improve it. Currently would need create fork or try make owner add to repo.
about game templates ready2use/etc. i see possibilities in non-sdk, but JME give so much freedom, so it depends if plugin-people would adapt them.
The easiest way I could come up with for contribution sharing was making a little app that pulled the repo and built it locally, but they had to be gradle based, which is an issue for older projects. It could also resolve the include/implementation string. That combined with a plugins/asset website would solve those issues. That’s what I’m working on myself. I just don’t like the “install this, install that” fragmentation of “utility tools” that are all around. That’s where the SDK should shine.
1 Like
Your approach was pretty inclusive.
My approaches would be based on public repo dependencies and not building locally. Which limits it to projects that actually publish. (Which may or may not be a good thing for a 'JME Approved" set of add-ons.)
After creating Maud, Wes, and DynamicAnimControl, I feel like I understand the old system pretty well. I hope that “gives me a leg up” on learning the new system.
Expect a 3.3.0-alpha1 release shortly.
3 Likes