I think I still have the ye olden branch where I tried to migrate OpenKeeper to use this new system. It should be fairly easy for me to test. At least for the LoopMode part, or can it be migrated. For the API part we are not the best to evaluate this.
1 Like
Note: right now, this would be the point I stop upgrading.
I use swing… so until glfw decides it wants to work properly with AWT, I’m stuck. Never mind the handful of other things that are still a little wonky with v3.
Edit:
Also, if we remove all physics from the “engine” then we may want to change what we call ourselves. jMonkeySceneGraph and then split off everything that isn’t animation or graphics related.
…not much of a game engine with no physics at all, I guess.
4 Likes
Were you being serious about dropping virtual reality? I was planning on figuring out how that works (and if I’m successful improving the documentation for it) in the new year
2 Likes
It wouldn’t be gone, just rolled into a separate library I guess like the other stuff.
I think right now we have no one contributing to it and even if they did, they might appreciate a more rapid upgrade cycle than JME’s once a year or two update.
1 Like
Yes, I understand that you might not be alone here; so how about “deprecating LWJGL2 for new projects”?
1 Like
I thought it was already deprecated.
1 Like
I think this is already doable, AWT and LWJGL 3. LibGDX is in the progress of making this happen. I tried to implement it for jME… But it requires quite a lot of expertise, not a lot of code it seems.
1 Like
Were you being serious about dropping virtual reality?
It was an idea I had, and I shared it in order to get feedback. So yeah, I was being serious. That doesn’t mean it’s going to happen.
This is a discussion, taking place during the earliest stages of planning. At this point, everything’s “on the table”. Nothing has been decided yet.
If the dropping of Nifty and VR are just moving them out from the CORE but to be still available in Mavencentral and as a projects under jME. Then I guess everything is fine. Just not very clear, I got scared too that do I need to also fork the Nifty support.
2 Likes
I thought it was already deprecated.
That would be news to me!
I did a quick search of jme3-lwjgl3 for the string “deprecated”, and all I found was “ARBDebugOutput.GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR_ARB”.
Furthermore, I see that LWJGL2 is still the default dependency in jme3-examples.
Are there specific filters you wand added or updated?
Mostly about filters quality, like SSAO / etc.
I also thought that some people wait for new render pipeline Ricc were working on.(no rush ofc here)
Are there specific improvements you want made to the animation system?
First of all - DOCS. Its really needed.
Also for example blending “frames” not “full-animations” option without tricks would be nice.
2 Likes
Changing the name would be difficult at this point.
So If we drop jme3-jbullet, then we must add a physics library to replace it? In that case, we could copy a snapshot of Minie v4.4 into the Engine. Of course, that would imply adding Heart and SimMath (or at least key parts of them) to the Engine as well. Between JME releases, I would continue developing Minie as a separate library.
The same approach could be taken with jme3-nifty. If we must provide a user-interface library as part of the Engine, we could drop jme3-nifty and copy a snapshot of Lemur into the Engine.
2 Likes
Yeah, I guess it’s true.
And while I see moving a an essentially unmaintained UI library out (Nifty) that “works like no other UI library on the planet” as a bit different than moving a well-integrated but very stale physics engine (jbullet) out, I suppose they are basically the same thing. (Personally, I’d move JME terrain out before jbullet but that’s probably bias because I actually find jbullet useful.)
We need to think of a strategy for how we want to develop examples, etc. going forward as we’re getting to the point where most of those will have to move out also.
3 Likes
Even if we were to drop
- LWJGL v2,
- the old animation system,
- virtual reality,
- jme3-nifty, and
- the FBX loader
and replace jme3-jbullet with Minie, (far from likely at this point!) I believe all that would only impact about 5% of jme3-examples.
What scares me about these ideas is how much Wiki updating would be required to properly support them.
It wouldn’t be gone, just rolled into a separate library I guess like the other stuff.
I assume that if we rolled jme3-vr and/or jme3-nifty into separate projects, nobody would maintain and release them. That’s what’s happened with jme3-blender and jme3-bullet/jme3-bullet-natives since they were rolled into Jme3Bullet and BlenderLoader.
1 Like
Can’t all of this be served like the LWJGL download page already does?
https://www.lwjgl.org/customize
We should provide a few sample gradle files that manages the reccommended components (and point out the “deprecated” status of LWGL2/nifty etc). I don’t see a valid reason to snapshot a library; most users will just want to grab the latest of everything anyway…
Wiki and examples should be marked as deprecated as well, and eventually hopefully be updated.
Also lbgdx does the same
1 Like
Could be that some are just obsolete. Blender and Bullet. The small minority still using them need to either start learning how to maintain these (yikes…) or migrate to more up-to-date solutions. I totally understand the need for these actions. Just a heavy burden to carry. I already see myself maintaining the jme3-nifty library 
Hopefully it doesn’t need much as the Nifty itself probably doesn’t get any new releases and maybe jME has a pretty stable API at this time…
I agree with @Pesegato that snapshots wouldn’t be the way to go. Maybe even no need to include. Just instructions, “want UI? get x”. SDK can be used to create build file with wanted dependencies. Even the web side could bake this build file (or just the dependencies in Gradle/Maven format) for experienced users to jump start their jME project in their favourite IDE.
2 Likes
I already see myself maintaining the jme3-nifty library
I have a fork of jme3-nifty you could probably use, and I’d love to have you as a collaborator/tester/user on that project.
I concur that new releases from void256 are unlikely. However, one of my ambitions is to transition my fork from Nifty v1.4.3 to StarCommander’s “1.5” branch.
2 Likes
Just want to remind you, that there is some people with less experience.
I remember that one fellow monkey using JME in his classroom to teach students.
What I am saying is: If it is to complicated to get even a small project started it might disencourage (new) users.
On the other side the question is: Who should and want to use the engine ?
Is it more hobby, should it be professional, is it for specialized people (replacing professional stuff) or should it be good and easy enough for pupils and students (like adi.bardas project) ?
2 Likes
Another thing for my wishlist for 3.5:
- GLFW Gamepad APIs integrated on InputManager
2 Likes
I totally agree with you. Trust me. That is why I’m trying to advocate the jME SDK even if for the professionals it is dogfood. But it would be the gate drug to get to jME when a person does not have any clue on any build systems or doesn’t even realize that jME is just a JAR file. It is entirely plausible to have some Java experience and a burning desire to create games but being clueless about Gradle and libraries. And hopefully via SDK (or other really easy start) mature into a healthy contributing adult monkey.
1 Like