Suggestions for v3.4

Yes, it is because it is free, so few people put a lot of energy into it. So my idea is to maintain based on the results of others, rather than starting from scratch, but there is still no compensation. I know that understaffing and no salary are the main reasons.
:joy:

I have got same ideas too about jmonkeyBuilder , since it’s javaFX so it would be awesome if we re-maintained , I have cloned it into intellij & tried to build but there seems to be some problems with google analytics & other unnecessary items there ,that sometimes I think causes unintentional crashes so it will take time , plus jfx is not available by the same means since jdk10 …so generally saying currently SDK is the best outstanding tool although I started to use pure code these days but the converter of the SDK is up-to-date !

2 Likes

Yes, I have read many articles, and I think the team currently chooses SDK or jMonkeyBuilder as one of the maintenance objects, rather than starting from scratch, which will reduce a lot of time costs. But the SDK is based on netbeans, not a pure visual editor, so I prefer jMonkeyBuilder. I’m still building jMonkeyBuilder recently, and I’m still studying the SDK source code.

2 Likes

Please , call me right away if you got something running in hands , the main problem is that the repository donot teach you about the code design pattern , so I am really still lost in some places that use OpenGL to render the viewport of working space & that seems to be running on a jfx panel or image view !

2 Likes

As much as I like the idea of a unified editor tool, I am a bit discouraged by its real possibility after the results of JmonkeyBuilder as well as Jayfella’s recent attempt at making one, and I would not suggest JMB to new users due to its many bugs and lack of continued development.

I advise against using Jmonkeybuilder because I encountered many scene-breaking glitches when I started making big scenes in JMB, and the developer abruptly abandoned it around the same time that I began experiencing many breaking errors that prevent me from even launching JMB with my current project’s asset directory. So I lost all of my scenes that I converted to the JMB .j3s scene type, as I could not convert them back to .j3o and I couldn’t launch JMB to keep working on them. Overall i regret using it, despite some good features it had.

I would love to see a larger new unified editor tool added, but I don’t know if I could muster up the courage to risk using it after my experience with JMB, at least not until I am sure it has strong community support. And I would most certainly cast my vote to extend the current SDK or make something new, rather than trying to revive JMB.

3 Likes

I’ve begun thinking about a v3.4 release of the Engine in March, but without any major features in it.

The big question in my mind is whether the v3.4 Engine should include jme3-bullet. We’ve already cut jme3-blender and jme3-jogl from master. This might be time to cut jme3-bullet as well. (However, I may be biased.)

10 Likes

I think this would be a great opportunity to cut jbullet from the engine.

Do you mean jme3-jbullet or jme3-bullet? Or both?

Oh, I was thinking jme-jbullet. But bullet native can also go.

1 Like

It’s hard. Physics is something that almost everyone wants where as blender support was a hot mess that would never fully work and jogl was unsupported and parallel.

…but given that it would just end up as its own project, still be in jcenter, etc… I don’t know that I care too much. As a gradle user it as much as doesn’t matter to me or my projects.

I don’t know if the SDK has worked out how to bundle these non-core things yet. (And if so, we made want to add some things to its list of things already bundled…)

1 Like

i remember current API that were working for all jbullet, native and Minie was stopping you from updating API to better one, so i agree that we might drop them in 3.4 (thats sad, but if noone support them, cant do anything more. jBullet is anyway almost like 10 years old without updates)

2 Likes

My vote goes for including at least one Bullet Physics implementation bundled with the engine. I think that’s what most people would want anyways for collision, raycasting, character controllers, vehicles, etc…

It’s something that people coming from other engines like Unity, Unreal or Godot would definitly be missing and it may put them off if not included out of the box.

Also if we would follow this path of stripping modules from the engine consequently, wouldn’t we end up with a super tiny JME with just the application and render stuff?
(a bit exaggerated but I hope you get my point)

2 Likes

I believe you are conflating “engine” with “SDK”.

All we are talking about here is moving some libraries over to contrib where they can have independent release cycles. They are already separate libraries. (jme-core doesn’t include physics OR demos, for example.)

What to bundle in the SDK is a separate issue but I’m not sure if that problem is solved or not with respect to moving something like jme-bullet out to contrib.

I do agree that there should be a physics engine “out of the box”… but what “out of the box” means is up to debate.

2 Likes

Ah I see, thanks :sweat_smile:

Well then my point was to include at least one implementation of Bullet with the SDK, so people coming from other engines have cool things like falling boxes and character controllers up and running quickly.

1 Like

Yeah, I think moving both the bullet native and jbullet to contrib would perhaps be best.

2 Likes

Currently the SDK includes jme3-bullet, jme3-jbullet, and Minie v3.0.

2 Likes

Does anyone know a way to create a Git repo that contains only the commits relevant to jme3-bullet, jme3-bullet-native, and jme3-bullet-native-android?

Otherwise I see two paths:

  1. fork the entire jmonkeyengine repo and selectively delete files from it (large repo including lots of history that’s not relevant to physics) OR
  2. create a new repo and copy the latest files into it (small repo that won’t include any of the history)

I did it with JME blender. It’s not hard, really to transfer a directory to a new repo and keep the history.

1 Like

Please point me to instructions.

Edit: note: as I recall, you can skip some of what he talks about as our case is simpler or something. Don’t be afraid to blow the target away and try again if something goes south. I think the first time I did this it took me two times to get it right.

4 Likes