Provide more detail and a better overview of the jME architecture for a developer level user. Instead of just stealing the introduction text.

Overview

jMonkey Engine (jME) was designed to be a high-speed real-time graphics engine. With the advances made with computer graphics hardware as well as that of the Java programming language, the need for a Java based game library became apparent. jME fills many of those needs by providing a high performance scene graph based rendering system. jME leverages the latest in OpenGL capabilities to push the capacity of the most modern graphics cards while providing ease of use for the game designer. jME was designed with ease of use in mind, while maintaining the power of modern graphics programming. The modular design insures that as computer graphics hardware improves and OpenGL improves to accommodate, jME will be able to quickly make use of the newest features. This same modular design allows the programmer to make use of as little or as much of the jME system as they deem fit.

At the core of the jME system is the scene graph. The scene graph is the data structure that maintains data of the world. The relationships between game data (geometric, sound, physical, etc) are maintained in a tree structure, with leaf nodes representing the core game elements. These core elements typically are the ones rendered to the scene, or played through the sound card. Organization of the scene graph is very important and typically dependent on the application. However, typically, the scene graph is representing a large amount of data that has been broken up into smaller easily maintainable pieces. Typically, these pieces are grouped in some sort of relationship, very commonly by spatial locality. This grouping allows large sections of the game data to be removed from processing if they are not needed to display the current scene. By quickly determining that a section of the world is not needed to be processed, less CPU and GPU time is spent dealing with the data and the game's speed is therefore improved.

While the scene graph is the core of the graphics elements of jME, the application tools provides the means to quickly create the graphics context and start a main game loop. Creation of the window, input system, camera system and game system are no more than one or two method calls each. This allows the programmer to stop wasting time dealing with the system and more time working on their own application. The display system and renderer provide abstractions to communicate to the graphics card. This is done to allow for a multitude of rendering system that are transparent to the end application. The main game loops are provided to allow for easy extension of the looping class and easy application development.

Actual rendering of the scene graph is abstracted away from the user. This has the benefit of allowing the swapping in and out of different rendering systems without breaking a single line of application code. For instance, if you run using LWJGL from Puppy Games, you could as easily switch to JOGL from Sun. There should be very little noticeable difference on the end system and no rebuilding of your project. However, to create a better API, the focus so far has been spent on adding features rather than maintaining more then one rendering system. Therefore, LWJGL is currently the only supported renderer. (A JOGL renderer has been created but not maintained, contact a developer if you are interested in this).

Each tool of the jME system was built using the basic building blocks. So all graphical elements will originate from the spatial class, all inputs and associated actions will come from the InputAction class, and so on. This will insure that consistency is maintained, and once the initial learning curve is overcome, using more advanced features will be substantially easier.

jME provides you, the programmer, with the tools you need to build your application quickly and efficiently. It will give you the building blocks you need to achieve your goals without getting in your way.