exactly what is jME I've realized that I've gone through most of the wiki tutorials but i just realized, what does jME do exactly. I had originally thought it was an all around game engine in which I could develop games using its library. But I've been wondering if its really a graphics engine. this question came up because I was searching around the site and found that it has lwjgl support and jogl. If it is a all around engine what use what I find for those other libraries and would I have to install them separately and import into my projects?
I read the wiki and site description about it but still slightly confused on the matter…
It does graphics, input handeling and audio. Aside from that there is also the physics engine (which is not part of the core at the moment). Libraries are included in CVS and in the releases.
To elaborate a bit more.
jME is an engine (library/API) built on top of OpenGL (which is, perhaps, the ultimate graphics library). Since Java does not have a OpenGL API on its own, it requires LWJGL (or any other GL binding, for that matter) to do its job.
Now, if you know something about GL, you might know that there is one thing it does very well… draw triangles on screen (and a bit less well other things like lines, dots, etc). However, if you wanted to create games directly on GL, you would have to do most or all of the logic yourself. Here is where engines come into the scene.
An engine is a set of utility functions/classes/programming paradigms/etc. That help you with data organization and manipulation. That, for instance, in real world, objects typically are arranged hierarchically (like a house being on the ground, a table being on a house, a book being on top of the table, and a bookmark in the book) That logic would have to be programmed by hand. The Scene graph in jME lets you think about that hierarchy and program with it in mind.
Also, displaying triangles is nice, but you need ways to interact with the user (like a mouse, keyboard, joystick), and you need to program what a particular interaction does in your 3D world… jME helps you there too, by adding a layer on top of jInput (which lets you access joysticks and whatnot).
Finally, a respectable game must have some sound, and there again jME comes into play with an interface on top of OpenAL.
As you can see, the technologies to build a game are all there, and there are more things even, but what an engine does is bring them all together, make them work and interact in meaningful ways, and letting use a single API for all those needs.
Hope it helps. 
1 Like
duenez said:
To elaborate a bit more.
jME is an engine (library/API) built on top of OpenGL (which is, perhaps, the ultimate graphics library). Since Java does not have a OpenGL API on its own, it requires LWJGL (or any other GL binding, for that matter) to do its job.
Now, if you know something about GL, you might know that there is one thing it does very well... draw triangles on screen (and a bit less well other things like lines, dots, etc). However, if you wanted to create games directly on GL, you would have to do most or all of the logic yourself. Here is where engines come into the scene.
An engine is a set of utility functions/classes/programming paradigms/etc. That help you with data organization and manipulation. That, for instance, in real world, objects typically are arranged hierarchically (like a house being on the ground, a table being on a house, a book being on top of the table, and a bookmark in the book) That logic would have to be programmed by hand. The Scene graph in jME lets you think about that hierarchy and program with it in mind.
Also, displaying triangles is nice, but you need ways to interact with the user (like a mouse, keyboard, joystick), and you need to program what a particular interaction does in your 3D world... jME helps you there too, by adding a layer on top of jInput (which lets you access joysticks and whatnot).
Finally, a respectable game must have some sound, and there again jME comes into play with an interface on top of OpenAL.
As you can see, the technologies to build a game are all there, and there are more things even, but what an engine does is bring them all together, make them work and interact in meaningful ways, and letting use a single API for all those needs.
Hope it helps. ;)
thx a lot that makes sense I had to ask though because when i was researching in other sites it came up under graphics engine which slightly confused me. To my understanding of your post with LWJGL integrated into it, its an all around Game engine, but then whats the point of JOGL i understand that its way more popular than LWJGL and supports awt and swing but is the only real reason of integrating it is to give developers more options when their working?
also since i'm able to build a basic game that means i'm already using LWJGL and the next logical step would be to research LWJGL tutorials and not just jME ones currect?
thx for the quick reply
LWJGL is not really less popular than JOGL. (quite the opposite some would argue).
You don't have to learn much about LWJGL to use jMonkeyEngine either. But to better understand how jMonkeyEngine internals work you could do that… a good understanding of OpenGL can help.
llama said:
a good understanding of OpenGL can help.
i think understanding OpenGL or 3D engines in general (at least the basics) is a must, else you will struggle from one problem to the next.
To answer the original question in very simple terms: jMonkeyEngine simplifies graphics programming.
You could almost think of it as a "translator." You program using jME's classes and methods, and those classes and methods do more complicated graphics work and output the results as if you had done the complicated graphics work.
In addition, it's a Scene Graph which basically generates your graphics in an efficient order.
Bonechilla said:
on the wiki tutorial page I also see jME Physics 2 is that part of jME or do i have to d/l it separate
you will have to download and set up jme physics separately
getting started with jme physics
To get started its best if you play with and modify the tests in the jmetest package, go through the tutorials in the wiki and look at the code of other projects.
some examples of a bit more complete demos/applications:
http://code.google.com/p/jme-demos/
http://code.google.com/p/monkey-mahjongg/
Part of the distinction is that, while JME is a bit more then just a graphcsi engine, its is less then a full "game engine" which is really a complete game minus scripting and art. A game engine typically comes with very advanced engine-sppecific tools to build the game.
JME is properly a "scene graph", plus a few other low level peices of functionality that relate closely to the scene graph.
I would agree it is a scenegraph rather than a game engine.
Whilst it comes with a few demos of implementing a simple engine, it leaves the implementation of the engine up to the developers.
Think it would be nice to create a package outside of the jmetest which contained more independant implementations, at the moment there are sources all over the place and it is hard for new comers to get started in the right direction.
on the wiki tutorial page I also see jME Physics 2 is that part of jME or do i have to d/l it separate from what I already have also to my understanding currently at my level I don't have to even think about fmodex which has to do with sound JGN which is for networking or fengGUI which i have no idea what does or is it good to try and learn each while I'm learning jME?
Core-Dump said:
To get started its best if you play with and modify the tests in the jmetest package, go through the tutorials in the wiki and look at the code of other projects.
Really think that getting started in this way for a new commer is unprofessional - lets face the facts, they need controller input, rendering, texture management, artefact picking, dynamic loading, path mapping... blah blah blah
The tests provided really are just simple tests - an efficient game needs a little more than copy and paste from the tests.
Think that a collaborated package outside of the jme suite would be the place to put real implementaton substance. Many peeps have contributed and will do.
but you have to start somewhere, and by playing/studing the tests you get to know how to work with jme.
The tests provided really are just simple tests - an efficient game needs a little more than copy and paste from the tests.
Think that a collaborated package outside of the jme suite would be the place to put real implementation substance.
Thats why i created the jme-demos on google code, to have a central place with some code which is a bit more complete and complex than the jmetest package.
Core-Dump said:
but you have to start somewhere, and by playing/studing the tests you get to know how to work with jme.
The tests provided really are just simple tests - an efficient game needs a little more than copy and paste from the tests.
Think that a collaborated package outside of the jme suite would be the place to put real implementation substance.
Thats why i created the jme-demos on google code, to have a central place with some code which is a bit more complete and complex than the jmetest package.
Eeek - well ahead of me , Nice call to have started a package on google code. Can this be managed, and also to be qualified to add to the JME standard of prime monkey ( erm, to be at least referred to in the demos page )
jmetests are one thing, game implementations are another
getting off topic here 
more discussion about jme-demos goes there
-> http://www.jmonkeyengine.com/jmeforum/index.php?topic=7596.0
lol yeah but its actually very helpful