With v3.2.3 of the engine out, it’s time to discuss why there hasn’t been a v3.3 and what (if anything) should be done about it. Here’s my understanding…
Early in 2018, @Nehon was championing v3.3. Here’s what he wrote in August: Next release(s) of the Engine - #3 by nehon
The driving feature of v3.3 was to be the new animation system (aka
com.jme3.anim aka MonkAnim). Since @Nehon became inactive, there’s been scant activity in that area. Meanwhile, the
master branch of the repo (on which v3.3 would presumably be based) deprecates the old animation system (aka
Being satisfied with (and deeply invested in) the old animation system, I’ve avoided using the
master branch except for bug fixes. I don’t know how usable or complete it is.
Animation is central to jMonkeyEngine, and the transition to the new system looks daunting. It’s not a one-person project. It will require new tests, tutorials, and documentation. For the SDK to support it, major changes must be made there too.
- Is anyone using the new animation system?
- Has anyone successfully transitioned an existing project from the old to the new?
- Should we release v3.3.0-alpha1 out of
master as it stands?
- Should we strip out the new animation system and release a v3.3 that’s mainly bug fixes?
- Is there some other new feature that might motivate a v3.3 release, and if so, what?
- Does anyone have both the time and the motivation to champion a v3.3 release?
Here’s an old roadmap (from 2014) that might give people ideas:
Roadmap for Future Release · Issue #198 · jMonkeyEngine/jmonkeyengine · GitHub
Here’s an incomplete list of issues and pull request that currently target v3.3:
Issues · jMonkeyEngine/jmonkeyengine · GitHub
As far as the new animation system goes, I have projects that requires the support for the glTF morph animations (I believe this is part of the new animation system, correct me if I’m wrong).
Yeah, I use the name animation system exclusively… and it’s what the gltf loader creates. So it’s basically also required by gltf.
Edit: so stripping out the new animation may also mean stripping out some/all of gltf support. At that point, a 3.3 release is not so interesting, I guess.
Another approach would be to un-deprecate the old system — at least until v3.4 — to reduce anxiety among developers still using the old system.
I personally am fine with it being deprecated. In my experience developers tend to ignore the deprecation notice and continue to use functions until they break
There’s a glTF loader in v3.2. It just doesn’t support morph animations.
Agreed. It does no harm. At worst it steers folks to give more testing to the newer code.
can i ask if all of old functionalities will work with new system but with different usage?
for example for my character builder based on bone loc/rot/scale.
deprecate old but leaving it working would be fine imo, if possible.
It should. Some things may even be easier, I guess.
Identifying gaps is one of the things that will be needed.
At what point does it make sense to update engine to jdk 1.8 before moving onto more features?
I thought Android still required 1.7. Is that not true?
I think there is limited support for 8: https://developer.android.com/studio/write/java8-support
EDIT: I do not know about support in netbeans though.
The main question is: If we don’t have features anymore, does it make sense to push out 3.3 just because it’s about time? I don’t think that makes sense at all.
Edit: And thus it depends on the state of MonkAnim, if it would be “usable”, we could release 3.3-alpha1 with MonkAnim as the Feature and work on Bugfixes, if not, there is not much point (provided GLTF already works in 3.2 as well)
imo new animation feature is big enough to even go standalone in 3.3 . There was done a lot of work, and there will be probably something more to do with it anyway i belive. its like 10 features in 1
Anyway i thought if @sgold you created Minie, so you could add some Minie features into it if possible. Also some of physics fixes with it that you already done. Anyway now is kind of late, because it require a lot of tests.
That would make a good feature set for v3.4
Note: pretty sure that “new animation system” and “MonkAnim” are two different things. And I believe Nehon said that the new animation system made some of MonkAnim irrelevant.
MonkAnim is still separate, no? I thought it was still on a branch.
There’s still a
monkanim branch in the repo. However, the PR that added the
com.jme3.anim package came from that branch. So it looks to me like they’re essentially the same thing:
I’m using 1.8 in my Android project and it seems to be working so far.
I have the motivation to help but the time… Well, that depends on my real job and of course my time with my family .
However, I can help you with little pieces, I guess.
Yeah, looks that way.
I know in the original design there was some state transition stuff like a state machine borrowing concepts from MechAnim. To support that, the JME animation system was rewritten to make it more flexible/blendable… and afterwards nehon said the other wasn’t so necessary anymore or something (or that his whole design would change).
So maybe there was never any code for that… but that was what MonkAnim originally was… an answer to MechAnim. Instead what we got was a redone animation system.
I am using it in my project and I like the design behind it. You can mix tweens to create action and play it with AnimComposer, tweens can be anything (animation, audio, particle, method call,…).
Yes, we have MonkAnim.v1 and MonkAnim.v2 and they are totally different in design.
v1 is here :
There is a state machine for anim transition and there is no tween system in there.
v2 is already in master which is completely different in design. There is no state machine and it is based on tweens.
New animation system is working fine for me (I have not tested morph animation so) and I think it is in a state can be tested by folks, so I am positive to releasing it.