jME 2.0 alpha source code released

From the posting I made over at the forums:

Here's what has made it in so far: (this list may not be all encompassing.)

* The batch classes and SceneElement have been rolled back out.
* We now use Enumerations pretty much everywhere in the API, making it a lot easier to figure out what values you have available. I've tried to comment all the tricky ones. We'll of course have more documentation to add, and I'm sure more Enums as well.
* 40+ new Image types supported, We now have support for all OpenGL1.1 image formats, as well as float formats (not tested though).
* We have 3 new mirror texture wrap types and now support specifying wrap on the R axis.
* We now support 1D, 3D and CubeMap textures.
* We now support 2 new Environmental map modes (NormalMap and ReflectionMap)
* 2 sided stencil support and stencil wrapping
* Lots more control over blending (including use of glBlendColor, glBlendEquation, glBlendEquationSeparate and glBlendFuncSeparate)
* New particle features: Timelines and animated textures. (With updated support in my editor)
* Some updated support for Collada, specifically we now have support for library_nodes, which is especially useful for loading in sketchup models. (Still not perfect, of course)
* Simple Bone and animation blending support. (Mostly this was checked in to keep us from having to maintain two versions of jME at work, I'd love to see the whole Bone and Skinning upgraded by a clever user or dev... hint hint.)
* New stats system... Instead of the old fps bar at the bottom, we now have a nice charting package. It's customizable, and you can turn off stats collecting at run time.
* Lots of small bug fixes and changes over the last 6 months that I can't remember...

Check it out from our svn repo.

Movie locked and loaded...

After spending the better part of three days total gathering, editing and splicing together footage from about a dozen different jME projects, the video portion of movie for our JavaOne presentation is finally done and just waiting for its soundtrack. The quality of some portions is better than others and I'm guessing Rikard and I should stick to our day jobs as a programmer, because we're no video editors... but I hope you guys all like it anyhow. Come see it unveiled for the first time at our tech session on Tuesday night of the conference. I may also get a chance to show it off on other days of the conference, so keep your eyes peeled.

For those of you who can't attend JavaOne this year, don't worry... I'll also post the video up to YouTube on May 10th. For now, here's a shot of it laid out in iMovie '08.

JavaOne '08 jME video in iMovie

Competition is GOOD

So some of you may remember an old comparison test I did a while back where I ran Java3D, Xith3D and jMonkeyEngine all against the same benchmark fly through of a Quake 3 level and recorded memory and frame rate. No? That's ok, it's been awhile and was already a bit hazy to me too. :) The short version is that jME came out ahead by a good margin.

Today however I was pointed over to a thread on the xith forums talking about how they were now the undisputed fastest java engine. Curious, I pulled down the xith source from svn and a copy of the old test from my blog post. Lo and behold, they were indeed running that particular test quite a bit faster (220fps - Xith and 180fps - jME... almost 20% slower!) Now, mind you, this test is of a completely static scene with a lot of shared textures, not really a living breathing Q3 level, but still... Was a very pleasant surprise to me. Kudos to the guy actually doing things over at Xith, Marvin Fröhlich!

Now as the title suggests, I feel competition is good because it helps you see where you can shave off the rough edges. After about an hour or so of playing with glIntercept the reason for the difference became clear (we were still sending several unneeded JNI calls in this particular test setup) and I happily brought the jME end of the test up to 235fps with some non-test specific upgrades to the jME core.

Actually, I was afterwards able bring that up to over 250fps (~15% increase over xith) by adding two lines to the test, letting the core know that it can ignore checks for new light states or cull states for this particular test.

Thanks for the push, Marvin, and nice work!