This mini-game contest will have the aim of everyone having fun participating and making a good game to showcase jME’s capabilities. There won’t be any genre or restrictions for the mini-game, only that it shouldn’t be too complex for the player to understand and play. The contest will take place between the 7th of November 2011, and the 31st December 2011 (inclusive dates). Below, you can find additional information, including the rules. Any questions are welcomed. Have fun participating, and good luck!

Judges: @memonick, @namo, @sbook.

Prizes: To be announced.

Please see the official Contest Rules Thread for all of the info!

Good luck to all!
The jME Core Team

I’ve always been into procedurally generated game development. Interestingly enough, my first big procedurally generated game was 3059 (a 2D “ASCII art” roguelike game). I went on to create FreeUniverse (a space action/trader game), Gentrieve (a procedurally generated Super Metroid game) and DroidCraft (Minecraft-like game for Android). Wanting to get into 3D programming (and back to my futuristic “roguelike” roots), I started 3069. I had planned an open, block-like world full of monsters, quests and items well before the Minecraft-era hit. I decided to use the Ogre3D engine, which turned out to be more difficult than expected. In the end, 3069 did get completed, but it wasn’t what I originally hoped for.

3079′s Conception

While taking a break from desktop game development, I played some great games: Fallout 3, Just Cause 2 and Minecraft. I loved Fallout 3′s action and role-playing elements, Just Cause 2′s grappling hook and Minecraft’s open, block-like world. Still wanting to create a solid 3D game, I decided to make another sequel to 3059 and 3069: 3079. Now running Linux, I needed a cross-platform development environment and I wanted to try a new, fresh 3D engine designed for games. I decided on Java and did a simple Google search for “3d engine java” — jMonkeyEngine was right at the top. Little did I know at the time how well jMonkeyEngine would work out!

Just another Minecraft game?

As the developer of Mythruna can attest to, it is a challenge to bypass the knee-jerk reaction of “it’s just another Minecraft clone.” To differentiate my game from Minecraft, I decided to focus on character abilities, artificial intelligence, action and questing (things Minecraft lacks) instead of crafting and mining (which Minecraft excels in). I also wanted the game to start in the sky, showing off the limitless ceiling while at the same time avoiding the “you start in an open field” Minecraft-like start. I do all this because I want players to know 3079 is not just another Minecraft clone — it actually plays much more like Fallout 3. Nevertheless, I’m continuing to look into ways to distinguish my game further.

Development

Performace, performance and performance. I started 3079 with the goal of making the fastest and leanest 3D voxel engine possible. At first, my engine was slow and inefficient. I had a node and separate mesh for every block and I was trying to use dynamic lighting. Once I figured out how to use Texture Atlases, I combined 40x40x40 “blocks” into a single dynamically-generated “chunk” mesh using a single material. I later ditched dynamic lighting and “baked” lighting into my textures. I did this by having a large grid of block textures, each with 16 different shades of brightness. I then set the correct shaded texture (using UV mapping) when dynamically generating the “chunk” mesh. This improved performance quite a bit — leaving more room for artificial intelligence (AI) processing. Figuring out how to connect “chunk” edges, especially edges of chunks that haven’t been generated yet, was quite the challenge; using specifically calculated random number seeds proved to be very important. Lighting also was a challenge — I didn’t get it “quite right” until very late in development. It wasn’t until I got performance greatly under control using the Java profiler before getting soft, ray-traced lighting to work (lots of internal caching going on!). All in all, programming the AI was the most fun — because making characters “act as expected” is always an interesting challenge!

Conclusion

I am very happy with 3079. Of course, it isn’t “finished.” I gave it the “BETA” label, because I still want to explore things like networking, “the look” and more unique tools and locations. I believe I really nailed performance and memory consumption which should give me quite the wiggle room to add more to the game. If you are interested in playing 3079, you can get a free demo at http://3079.phr00t.com/.

My thoughts on jME3

Using jME3 was almost a breeze. Getting started was very easy after installing the jMonkeyEngine 3 SDK and downloading the first tutorial project. I especially liked how SimpleApplication included the flying camera and graphics configuration window — I could immediately get started on my game without having to re-invent the wheel here. The forum community was also very helpful and I greatly appreciate all the prompt help I received. Once I started using the nighly SVN (to get daily jME3 updates with Alpha-4), problems I had with the engine were fixed in only a day or two. Now that jME3 BETA is here, things are stable enough where I don’t need to use the nightly SVN.

jME3 was a whole package. It wasn’t just a library you add to your current NetBeans installation — it was a whole SDK There are a few plugins for the SDK that I used, like the model importer and desktop deployment tool. However, there are many others I didn’t get to — like the vehicle and terrain editors (which I’m sure many would find useful).

jME3 Pros:

+ Small learning curve: jMonkeyEngine 3 SDK + tutorial project (using SimpleApplication) = easiest start to a 3D engine ever!
+ Performance: jME3 takes care of view culling & scene management in an efficient manner
+ Java platform: cross-platform support!

jME3 Cons:

+ Not “stable” yet: jME3 is progressing very well, but isn’t fully mature yet. I had to create my own shader for proper fog effects because they haven’t been implemented yet, and some bugs were difficult to work around until they got fixed in nightly releases

With jME3 nearing its first stable release and many monkeys already getting their hands wet with creating games we thought it would be good to implement a demo game with jME3 to a) showcase jME3 and one possible way to implement a game with it and to b) verify the jME3 API in terms of usability ourselves. Furthermore the game is planned to stay as a community project that will be extended and improved to further test and showcase jME3.

So I wrapped up my ideas and started off with a blank BasicGame project in jMonkeyPlatform and one week later I already had a first version of a game including networking running. Yes, one week. I was baffled myself about how efficiently and fast one can write games in jME3. In that one week I got more done than in one full year messing with jME2 RenderStates Have a look at the first results:

It looks very simple and plain but in the background most of the system detailed below is already implemented and the best thing is the design makes it possible for others to edit maps, vehicles etc. in jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. w/o changing the code, allowing designers to contribute easily, if you feel like contributing assets or working on parts of the game code, drop me a note!

So keep your eyes open for updates and news and in the meantime read about the game implementation details below.

The Game

Since the time I started working with jME I always wanted to create a game like Activisions “BattleZone” from 1998. This was actually the initial reason I started working with jbullet physics and because the idea was floating around for some time its also the reason why @nehon created the awesome HoverTank model. BattleZone was a FPS game with RTS elements or vice versa, however you want to look at it To get an impression of the original game, have a look at some gameplay of the original version.

Implementation Details

MonkeyZone is a physics-based networking game. Both clients and server run the physics simulation, the clients send input data from the human and AI players to the server where they are used to control the entities and also broadcast to the clients. Additionally the server sends sync data in intervals for all objects in the game to prevent drifting.
When a human user or an AI presses a button/performs an action the actual logic is done on the server and the results are broadcast as data messages for the entities. When the entity is controlled by an AI the actual AI code that determines where the entity should move and when it should perform an action is executed on the client.

Note that the way MonkeyZone is implemented is just one of the many possible ways to do a game like this in jME. Some things might be done more efficiently, some might be done in another way completely. MonkeyZone tries to do things the way that are most appropriate to implement the game at hand and it shows nicely how jME3 and the standard Java API can make game development easier and faster. Also note that the way MonkeyZone is designed is not scalable to a MMO style game, it will only work in a FPS style environment where the whole game world can be loaded at once.

Terminology

The game uses certain terms that might be familiar to you but maybe used in another way, so heres a quick rundown on the terms being used.

Manager Classes

The WorldManager does the main work of organizing players, entities and the world and synchronizing them between the server and client. Both client and server use this class. Some other managers like ClientEffectsManager only exist on the client or server and manage e.g. effects display.

The gameplay is largely controlled by the ServerGameManager which does gameplay logic on the server, combined with the actions issued by the AI and user on the client (see below) it implements the gameplay. It extensively uses the functions exposed by the WorldManager to perform actions and gather data. This is also the class where the actions of the players are actually executed on the server to determine the outcome (ray testing for shooting etc.).

Use of Controls

Controls are used extensively in MonkeyZone for many aspects of the game. When a player enters an entity the Spatials Controls are configured based on the player that enters. For example when the human user enters an entity, Controls that update the user interface (DefaultHUDControl) or user input (UserInputControl) are added to the current entity Spatial.

As entity capabilities

Controls attached to Spatials are generally used like an “array of capabilities” that the entity posesses. So when an entity has a VehicleControl its expected to be a vehicle, when its got a CharacterControl its expected to be a character.
Other Controls work completely on their own, like CharacterAnimControl which just uses the CharacterControl of the entity to check if the character is running, jumping etc. and then animates the entity if it has an AnimControl.

To abstract

Furthermore theres special interfaces for Controls that allow abstraction of different Controls into one base interface. For example ManualControl and AutonomousControl are interfaces for controls that manage the movement of a spatial in a generalized way. This way AI code and e.g. the UserInputControl only have to check for a valid AutonomousControl or ManualControl on the spatial to control and move it. The details of the movement are handled by classes like ManualVehicleControl and AutonomousCharacterControl.

For AI functions

A special Control called CommandControl handles the Commands that can be executed by user controlled players, see below.

Artificial Intelligence

MonkeyZone includes simple AI functions based on a command queue.

Commands

To implement autonomous AI players MonkeyZone uses a system of Commands that are managed by a CommandControl that is attached to each AI player entity controlled by the user. This CommandControl manages a list of Commands that are executed based on priority. For example theres a MoveCommand, a FollowCommand and an AttackCommand, Commands can however implement more complete behavior than that, e.g. the complete logic for a scavenging entity.

Triggers

The SphereTrigger is a TriggerControl that is also attached to each AI players current entity. It consists of a GhostControl that checks the overlapping entities around the entity its attached to. It can be assigned a command that is checked with every entity entering the SphereTrigger and executed if applicable (e.g. normal “attack enemy” mode).

NavMesh

For each map a navigation mesh is generated that allows the entities to navigate the terrain. Autonomous entities automatically get a NavigationControl based on the current map. The AutonomousControl implementations automatically recognize the NavigationControl attached to the Spatial and use it for navigation. The NavMeshNavigationControl implementation contains a reference to the levels NavMesh and implements a navigation algorithm similar to the A* algorithm.

Networking

Networking is realized in the PhysicsSyncManager which we hope to extend to a state where it can serve as a general sync system for physics based network games.
The sync manager basically puts a timestamp on every message sent from the server and then buffers all arriving messages on the client within a certain time window. This allows to compensate for messages arriving too soon or too late within the constraints of the buffer, a future version might step the clients physics space different to compensate for network delays without “snapping”.

Use of jMonkeyPlatform tools

All assets used in the game, like entity models and loaded maps can be preconfigured and edited using jMonkeyPlatform. For example, to add a new vehicle type, a vehicle is created in the jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. vehicle editor and UserData like Speed, HitPoints etc. is applied directly in the editor. When the model is loaded in the game it is automatically configured based on these settings, the same accounts for maps that are loaded, special Nodes that mark e.g. player start locations are recognized automatically etc.

UserData

Entities that are loaded from disk have certain UserData like HitPoints, Speed etc. that is used to configure the entity at runtime. jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. allows adding and editing this UserData so entity properties are editable visually.

Physics

VehicleControls, CharacterControls and RigidBodyControls with mesh collision shape for terrain and objects are generated in jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. and saved in the entity j3o file. When an entity is loaded, the type of entity is identified based on the available controls and UserData and it is configured accordingly.

The Future

I hope to get to talk about MonkeyZone some more when it gets more mature, for now have a look at the code and feel free to ask about it, if you want any new features, you are free to implement them

MonkeyZone is hosted at GoogleCode, where you can checkout the jMonkeyPlatform project via svn:

Team->Subversion->Checkout and enter the URL http://monkeyzone.googlecode.com/svn/trunk/
After downloading and opening the project, run a server first and then a client.

Cheers,
The jMonkeyEngine Team

This effect is based on Wojciech Toman’s Rendering Water as a Post-process Effect published on gamedev.net.

Explanations

In this article the author uses the effect in a deferred rendering process, taking advantage of the pre-computed position buffer and back buffer (a texture representing the screen’s pixels position in view space, and a texture of the rendered scene).

After some calculation this allows to reconstruct the position in world space for each pixel on the screen. If a pixel is under a given water height, let’s render it as a blue pixel!

Blue pixel? Not exactly, we want waves, we want ripples, we want foam, we want reflection and refraction.

The GD.net article describes how those effects are achieved, but the main idea is to generate waves from a height map, create ripples from a normal map, blend in the foam texture when the water depth is below a certain height, compute the refraction color with a clever color extinction algorithm, and then, display the reflection and specular effect by computing a Fresnel term (like in standard water effect). In addition this effect, allow to blend the water shore with the ground to avoid the hard edges effect of classic water effects based on grids or quads.

How did we implement it in jME3?

jME3 default behavior is to use a forward rendering process, so there is no position buffer rendered that we can take advantage of. But while rendering the main scene to a frame buffer in the FilterPostPorcessor, we can write the hardware depth buffer to a texture, with nearly no additional cost.

I won’t go into the details of this, but there are several ways of reconstructing the world space position of a pixel from the depth buffer. The computational cost is higher than just fetching the position form a position buffer, but the bandwidth and the memory required is a lot lower.

So.., we have the rendered scene in a texture, and we can reconstruct the position in world space of each pixel… We’re good to go!

Usage

There are two tests cases in the jME3 repository :  TestPostWater that is the test caseA small, self-contained application class that shows the effects of a problem. It should use only default assets so that it can be posted in the forum in code tags and run as-is by the developers. shown in the video above, and TestPostWaterLake that is a test with a more calm and muddy water pond.

Those test cases demonstrate two main characteristics of this effect :

• OMFG!! friggin awesome!!!
• Highly configurable effect that can render any type of water

Enjoy little monkeys!

Nehon

Please make a brief introduction of yourself. -What’s your background in programming / game development? -When and how did you start your journey with jME?

My Name is Dennis Franke, 21 years old and I’m currently living in Braunschweig, Germany, and I study Computer Science at the TU Braunschweig. I started programming when I was about 13 years old with HTML and PHP and continued programming with PHP for about 5 years. After learning C++ and Visual Basic for a short period of time I switched to Java and stayed with it until now. Besides some small 2D Games with Java I made my first small 3D-Game with Java3D, but since Java3D is pretty much dead and there weren’t that many people that could help me, I decided to use JMonkeyEngine instead.
My first Game with JMonkeyEngine 2 was a small Game about the TV-Series Scrubs where you could walk around in the hospital and do a few Missions.
When I saw jME3 come out I decided to do another Game with the JME and so I started working on Return of the Warlord, but I never really finished it, since the Basis of RotW was a little messed up and after a short break I started with the first Prototype of Marble Mania.

By itself an impressive one-man effort, Marble Mania is the first complete game powered by jMonkeyEngine 3. What possessed you make a game with early alpha software?

Since I already knew from my experience with jME2 that the Community is really friendly and always helps I figured why not do some testing with jME3 and after the first few tests I really liked jME3 and so I also used it for Return of the Warlord and Marble Mania and until now I didn’t regret my Decision to use jME3. Most of the time there were only small changes to the API and so I never really had trouble after updating my Source with the SVN. Only a couple of times it took some time to fix some Issues I had after updating.
In my Opinion jMonkeyEngine 3 is already really stable and there are only minor changes to the API, so I can advice everyone thinking about using jME3 to do so.

How many hours do you reckon you’ve put into this game? When did the initial design stage begin?

I had the initial Idea for Marble Mania at the end of last Semester, which would be somewhere around July. During the Semester break I wrote the first small Prototype and collected some Ideas, for example the Skills were actually not planned in my first Prototype. Since then I’ve spent a LOT of time working on Marble Mania. I don’t have an exact number, but if I would have to guess I would say I spent at least 100 Hours working on Marble Mania.

What are your plans for the game?

For now my Plan is to get a stable Version ready and online and do some Marketing for Marble Mania, so that some People are actually playing it. My Goal is, that there are most of the time a few People playing so that you can just start the Game and there are already People online and you can just start playing against someone else, without having to wait until somebody else joins the Game.
Everything more than this goal is just a bonus for me.

I’m also planning some fun stuff for the Release of Marble Mania, but I’ll let you know more about that later.

What kind of work took up the majority of your time; toolsets, graphics, game logic or something else entirely?

Most of my time I spend working on the game logic and creating the game design of Marble Mania and right now I’m spending most of my time working on the Network-Layer for Marble Mania, because there are a couple of bugs left in SpiderMonkey that are holding me back from releasing a (hopefully) stable Version. But the Bugs should be fixed pretty soon and then I should be able to get a stable Version out there.

The graphics for Marble Mania were actually done pretty quick, because I’m really bad at designing graphics and I thought I would just create some placeholders for now and change them later, but after I saw the graphics in the Game I enjoyed the look of it and so I decided to keep them.

Along with being an early jME3 adopter, you were maybe the first developer to adopt SpiderMonkey. How would you say SM matched up against your initial networking implementation, and what pros and cons are there to speak of?

Compared to my own network implementation, which was still in a really early state, SpiderMonkey is much faster and SpiderMonkey also has some nice Features that make working with it much easier. Most of the time they are only some small Features, e.g. I enjoyed that I could add a Message-Listener for an specific Message.

SM also needs much less Heap Space than my own Implementation, which was based on Threads and java.io instead of java.nio. Thus I had to create a Thread for each Client which needed a lot of Heap Space.

Based on my experience with SpiderMonkey it is going to be a really cool feature of jMonkeyEngine.

You used NiftyGUI for your interface. Any constructive feedback to offer the library’s author?

I really enjoyed working with Nifty GUI, because in my Opinion it is really intuitive, but I had some trouble getting used to the layout in Nifty GUI.
I’m not quite sure wether there is some new Documentation online, but when I started working with Nifty GUI there wasn’t that much documentation about the layout in Nifty GUI.

Another thing is, that I find it kind of complicated to change for example the Images for a button or a textfield, so I would really appreciate it if the author could change it, so that it’s easier to change the Image, for example by defining the image in the XML-File.

Other than that I had lots of fun working with Nifty GUI and was impressed how easy it is to create a good-looking Menu with Nifty GUI.

Could you go into some detail about your art pipeline?

I’m not quite sure wether you really want to call it an art pipeline, because I didn’t really do that much art for Marble Mania, but I did some Prototypes to test the gameplay and see what it looks like and if it could be fun to play.

I also made some drawings of the different menus and for the Level-Design I did some paper-prototypes to check wether they could be fun or not and since they only contain basic shapes I decided to code the levels directly into the Source instead of importing them, which gives me much more possibilities than having to write everything into the importer.

All other art in Marble Mania was created pretty much on the fly when I needed them, so there isn’t really an art pipeline.

Best and worst parts of jMonkeyEngine 3.0?

Best parts:
- Already pretty stable (only minor changes to the API)
- Easy to start with
- Great Physics-Implementation
- Easy to create a GUI with Nifty GUI
- Great Network-Layer

Worst parts:
- The new Material-System is kind of confusing in the beginning

A big thanks to Dennis Franke for taking the time aside to answer the questions for this interview.

Go check out the Marble Mania project listing here on jmonkeyengine.org to keep up with the latest tweets and blogposts from the developer site Bazinga Productions.

This release sees many additions like terrain and networking and also jMonkeyPlatform has been improved with many additions and fixes. To celebrate the achievements, we have created a new video for this release, showing some of the code examples and jMonkeyPlatform in action. Enjoy:

The newly added terrain and networking systems have been tested by users of the nightly version and most bugs have been squished already. See a list of the most important changes in jMonkeyEngine3 SDK Alpha-3:

jMonkeyEngine
- Terrain system
- Networking System
- Blur filter
- Glow map textures
- Bullet physics now an AppState (easily create/switch multiple physics spaces)
- More/Updated tests
- Local updates (no more rootNode.updateGeometricState())
- Fixes (AssetLinkNode, Collision etc..)

jMonkeyPlatform
- Welcome Screen
- Model Import Wizard
- Asset Packs
- Codeless projects (manage other IDE projects assets in jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK.)
- NeoTextureEditor & NeoTexture plugin (via Contribution Update Center)
- Desktop and Applet Deployment
- NiftyGUI XML Previews
- Terrain Support (Editor WIP)
- Binary Ogre files support
- Improved Help System (Docs are stored local, search works now)
- Add jMonkeyEngine3 wiki content to Help System
- Bugfixes (e.g. edit-resistant example projects etc.)

Uninstalling jMonkeyPlatform Alpha-2
For all existing users its recommended that you uninstall your current version of jMonkeyPlatform without deleting the settings folder and then install Alpha-3.

Windows:
- Select jMonkeyPlatform in your installed software list and uninstall it
- (Alternatively) Double-click the uninstall.exe in the jmonkeyplatform folder
- Go through the uninstall wizard

Linux:
- Run the uninstall.sh file in the jMonkeyPlatform install folder
- Go through the uninstall wizard

MacOSX:
- Right click the jMonkeyPlatform application and select “show contents”
- Double-click the uninstall.command file in the folder that opens
- Go through the uninstall wizard
- Delete the empty jMonkeyPlatform application.

Downloading jMonkeyPlatform Alpha-3
Download jMonkeyEngine3 SDK Alpha-3 in our download section.

Happy coding,
The jMonkeyEngine Team

SpiderMonkey is a high performance Java networking engine. It is efficient, yet simple to use. Setting up a client/server mechanism requires no more than basic Java knowledge. The same goes for sending and receiving objects – in other words: Every monkey can use it!

jME3 now has a default networking engine

Let’s start with that SpiderMonkey is now part of jMonkeyEngine 3! This means that you monkeys can now use networking straight out of the box. You can find SpiderMonkey in the latest SVN revision – let us know if you run in to any problems; we’re always happy to assist you!

SpiderMonkey 0.9 – first alpha

This is also the right time to announce the 0.9 alpha version of SpiderMonkey! After about a month’s work, I feel it’s far enough to put it out there. With the help of pgi, Ractoc, and Creativ, we’ve managed to get SpiderMonkey as bug free as possible. There are, of course, always more bugs to be found – that’s where you come in

• JAR here
• original source here, new source here (so fetch the latest source if you’re already set up with jME3).
• documentation here
• support here

Do note: SpiderMonkey will still be available as a separate JAR if you choose to use it outside of jME. Happy networking!

~ Lars Wesselius “Levia”

Many improvements have been made to the core jMonkeyEngine as well as to the jMonkeyPlatform since Alpha-1 and generally jME3 is gaining more and more steam. We are happy to see many new users and even contributors and that tells us that we are on the right way. Everybody is very determined to make the jME3 SDK a premier OpenGL and game development tool and we are just as eager as you to see a beta soon .

See a partial list of changes hee:

jMonkeyEngine

• PSSM / SSAO
• Picking / Collision fixed
• New Input System
• Many Physics improvements, esp. Vehicle
• Physics load/save
• First implementation of a water shader (WIP)
• Many small bug fixes and added methods

• Way faster jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. due to fixed logging bug
• Material (j3m) editing in jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. (video)
• Improved SceneComposerA plugin in the jMonkeyEngine3 SDK, allows editing the content of j3o files which represent a complete scene or model. (see video below)
• Linking of models into scenes (see video below)
• Physics support in SceneExplorer
• Texture editing tool
• Online Documentation for jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. and jME3 via “F1″
• GLSL Code Editor (Contribution Center)
• Collada Import (Contribution Center, Alpha)

This is the first release that introduces a new installer and by using advanced compression, we were able to reduce the release download size to 75MB, including jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK., jME and all test data.

jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. alpha-2 also introduces the “jMonkeyPlatform User Contributions” update center. If you go to “Tools”->”Plugins”->”Available Plugins” you can install some new plugins to jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. that are not part of the core jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. but have been contributed by users or are packaged from external libraries/projects (Category jMPThe jMonkeyPlatform, a full-fledged IDE with plugins for editing jME3 content and assets. Integral part of the jME3 SDK. User Contributions).

Download jMonkeyEngine3 SDK Alpha-2 for your OS now:

• Windows
• MacOSX
• Linux

If you have problems after installing, delete your jMonkeyPlatform settings folder:

Windows: C:\Users\<username>\AppData\Roaming\.jmonkeyplatform
Windows (alt): C:\Users\<username>\.jmonkeyplatform\
MacOSX: /Users/<username>/Library/Application Support/jmonkeyplatform
Ubuntu:  /home/<username>/.jmonkeyplatform

Happy coding,

the jMonkeyEngine Team

Everybody in the 3D computer graphics neighborhood has heard about SSAO, but what is really hiding behind those four letters?

If you want to know, this paper is for you. This is a quick abstract on the technique, with a focus on how it has been implemented for JME3.

What is ambient occlusion?

Ambient occlusion refers to the shadows that nearby objects cast on each other under an ambient lighting. It‘s an approximation of how light would radiate in a real life scene.

It usually entails casting rays from each point of a surface in random directions; lighten the point if the ray reached the background, darken it if the ray reached an object.

As you might have guessed, this method put a heavy burden on the CPU, and is not yet exploitable in real time 3D.

However in 2007 Perumaal Shanmugam and Okan Arikan released a paper on a hardware accelerated implementation available here.

For something strictly technical, check the official comparison of the two engines.