jMonkeyEngine.org

Due to me adding android support, I had to re-organize jme3 source folders so that desktop and android dependencies can be separated. For that reason, I decided to add a new branch rather than breaking the current one. The branch called mf_jme3test is no longer in use by jme3. The new, re-organized branch is now stored in /branches/jme3. Anyone who is currently using jme3 is expected to migrate to the new branch as the old one may be deleted at any point of time.

Android support is not currently in SVN, some parts of code are still in motion and need to be adjusted for android in order to work properly. It is expected that Android support will be added in the following week.

To use the new branch of jme3, you must include one or more "source packages" from the source folder. See this wiki page for more details:

http://code.google.com/p/jmonkeyengine/wiki/SourcePackagesJme3

Cool, Android support will be awesome!

Very nice indeed!  I will be getting a Nexus One in the next month or so and will definitely take jME3 through its Android paces when I do.  I am very interested in testing the waters of ~that~ market.

OT Question: I just looked through the reorganized jME3 branch and find that there is still alot of G3D named stuff out there.  Will this change at some point back to jME or is G3D (at least at that level) here to stay?  If its going to change, I would think that changing it sooner rather than later would be better!

ashtonv said:
Very nice indeed!  I will be getting a Nexus One in the next month or so and will definitely take jME3 through its Android paces when I do.  I am very interested in testing the waters of ~that~ market.

Welcome to my list of people I'm jealous of ::shakes fist::

On Topic:  Kirill, it looks like jME3 might end up being used in Betaville after all, we're very interested in mobile.  This might be my prompt to get our jME2 binaries into jME3

Core-Dump said:
cool, i wonder how the performance of jme3 on phones will be.
I guess on the nexus it will be quite ok, but older phones like the g1 might suffer a bit.

There are some parts that really should be optimized, on the data side. You want materials for example which are text-based in jME3 to be converted to more efficient, binary based materials. Same thing goes for models. With that done, the only performance limit is of the algorithms and polygon throughput.

EDIT: First screenshot!

Excellent news! I've taken up android programming in the last months and will definitely check this out.

Well done!

erlend_sh said:
But isn't it really just a matter of renaming, as in, moving over to a properly named branch? I have to say, the G3D tag has come up every so often as a confusing factor to new users; we'd be much better off without it.

It shouldn't cause too much trouble to rename/refactor the packages from g3d to jme.  I mean this ~is~ jME 3.x and not "Gorilla 3D", right?  I think that it would be best to make it jME all the way through if that is the case.

normen said:

erlend_sh said:
But isn't it really just a matter of renaming, as in, moving over to a properly named branch? I have to say, the G3D tag has come up every so often as a confusing factor to new users; we'd be much better off without it.

if the package name is com.jme again the questions will not be about "why is it g3d?" but "where is my class XXX from jme2?" I think a very strong hint (like package name) at the fact that this is a new engine might be good..

This is really the case of keeping external and internal "branding" the same.  One or the other should be used, but not both.

As to the jME 2 vs jME 3 class differences, I would suspect that anyone using jME 3 would know that they are using it and would hence not be too confused or upset to discover that jME 3 com.jme  differs significantly from jME 1 and 2.  Software and API rewrites happen all the time and the major version number change indicates that something very significant has changed.  Strong documentation for jME 3 should further drive this point home to the user.