jME3 the GUI is growing on me

Random bonus jME3 video of something I’m working on!

Well… I’ll own up where I’ve been wrong in the past, and I have to say that dismissing the jMonkey IDE out of hand was probably a big mistake.

To understand where I’m coming from you’ll have to remember some ten or so years ago, heavy weight java applications like for example (and it wasn’t the only one!) Eclipse – just weren’t up to the job.  In fact at the time they were the worst possible advert for Java there could be.  They were usually clunky slow and generally did a real stand up job of getting in your way and slowing you down…

Don’t forget for may years I’ve considered anything more than find/replace in a text editor basically overkill, and lets not get me started on Intelliguess(tm)

Now I did have to wrestle a little bit at first with the jME3 SDK, because of a rather odd updating bug with my OS of choice I was forced to compile and produce a distribution zip from the svn version before the SDK would update itself, but these things happen…

So why did I go to all that effort? Well its not just one killer feature but rather an accumulation of small features I like the convenience of…

First off, and of most importance it isn’t clunky, its fast and responsive – while by default there is probably a few too many docked window for my taste you can soon move things around and get a good view of your code.

Engine integration – say for example you create a new controller for your scary aliens, any class fields that have getter and setter methods can be edited via the sdk, this means if you have a few objects in the visual scene editor you can edit their parameters within the SDK.

Material editor – when you create a material in the SDK the material editor allows you to directly edit the code but there is also on the tab next to the material source a GUI editor for the material, from included common material definitions or your own custom definitions you can then fill out properties such as which textures to use (with custom texture selector showing the textures in your assets)

Art path – There are a few different routes from blender (or other packages) into the SDK and while I have has some minor issues there is at least more than one way to skin a cat here, long and short of it is you can soon get assets into the SDK and start visually moving them around a scene and adding behaviors (called controls by the SDK)

javadoc integration – most IDE’s do this and its just typing /** and bingo all the parameters are sat in @param tags ready to be described nice little time save use it, when you get back to the code in six months or even years later you’ll be glad you took the time…

While I really struggled with Unity and really cannot get on with C# nor for any serious use Javascript.  In contrast although initially jME3 took a little getting used to, I have to say I’m a convert.

Only problem is Java’s slow right? – Wrong! that old meme is just so far wrong it ain’t even funny even more, in addition quite irrelevant given the state of current hardware – even my modest laptop with integrated graphics is getting a solid 60fps with a large physics landscape and a dozen physics controlled cars, oh and 40 or so physics controlled “bricks” several particle based explosions and several dozen spheres representing cannon balls!

Slow it aint…



Leave a Reply

Your email address will not be published. Required fields are marked *