Research Questions around JMonkey Engine 3

Edit: that being said, if you make super crazy scene graphs of 1,000,000 of tiny objects then JME does have a way to batch that stuff into instances. This would be similar but 1000x more flexible than Java3D’s compile().

-I’m sorry, but in real terms what do you mean? I can’t interpret the vernacular here.

9#) When it comes to professional use, does JME3 have the same kind of reputation as JReality or Ardor? Do people just see the name of JMonkey Engine 3 being juvenile, and something just meant for computer games? What do people choose in the field of medical imaging, for example?

1 Like

Objection your honor, argumentative and vague.

Define reputation and juvenile in this sense. Tells us why you are asking these questions instead.

1 Like

i just did look at JReality Gtihub:

  • only 2 watch 6 stars - like noone use it?
  • last update like 10 years ago
  • it have multiple licenses (like they told in github readme)

did i look at wrong repo?

so i did just look at Ardor3D repo and i see:

  • only 29 watch 185 stars (so someone use probably but not a lot)
  • updated almost year ago
  • i also see last commit comment “Replaced syncronized blocks and list with ReadWriteLock”
    with syncronized word instead synchronized. Im not native English speaker, but i assume its incorrect - so i dont see it be more proper for a “professional non-game use”…

Then i look at JME github repo:

  • 208 watch 2885 stars
  • last updated days ago

Also i seen non-game projects made with JME.

i really dont understand something here. Please explain me @Z1234

Assume i would need to make 3d non-game project (well we all work somewhere). I would look at this things to decide first. JME looks much more professional for non-game than this 2 repos when i just look at repos github. Why not then? Do you need it to work on Java 5 or something?


The reputation of the development tools that one use are ultimately meaningless to the customer / end user. They will (or at least should) judge your application as juvenile or not depending on the quality of your finished app and your company’s reputation. Other developers might judge you for using JME, but others would judge you for using other engines, and a lot of developers would judge us all for using java even though they’ve never used it outside of a school setting and don’t know what they’re talking about. So I would not worry much about being judged for the tools you use.

I have no clue about 3D medical imaging, and I don’t believe that anyone in the JME community has used this engine for those purposes that I’m aware of. But if you are inferring that you are worried about the engine name “Jmonkey” sounding juvenile / game-ish / un-professional, then you could easily avoid telling customers what engine you used to develop the app, and they would likely never find out unless they know what program files to look for.


Interestingly a company I work for (that I probably shouldn’t namecheck on the internet) that is a 3D medical image company did investigate using JMonkeyEngine for visualising organs etc in 3D. Was before my time but my understanding was that ultimately the project didn’t happen but they were happy with JMonkey and would have used it had it of gotten off the ground (It would have been a building a mesh in memory based on CT data thing)


Yeah, after having dealt with many OpenGL abstraction layers over the years, JME’s direct wiring of VertexBuffers was very attractive. To have a whole scene graph where I can still poke things directly into buffers was super powerful.


-Edit: that being said, if you make super crazy scene graphs of 1,000,000 of tiny objects then JME does have a way to batch that stuff into instances. This would be similar but 1000x more flexible than Java3D’s compile().

Can someone kindly re-submit what this person meant about this comment, since I don’t yet see what on earth they are particularly referring to, or describing. ?

Batching is the process of combining many individual geoemtries in the scene graph into a single geometry to increase performance. This is helpful because 100 geometries (aka scene objects) that each have 10 vertices will (in most cases) be less efficient than 1 geometry with 1,000 vertices. So you can batch them into 1 single geometry to increase performance.

Here’s the documenation about batching
(Optimization reference :: jMonkeyEngine Docs)