Re-organization of jme3 branch, Android support

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

Great news!!!

Cool, Android support will be awesome!

Okay everything is in working order. I just need to finish android's asset manager and add fixed-pipeline support to the renderer and jME3 should work smooth on it  :wink:

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:

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!

There is no plans to use com.jme or com.jmex packages since the new jme3 is quite a different beast than version 1.0/2.0.
Probably the g3d package is here to stay.
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 :D

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.

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!

Huzzah!  You're working in Netbeans, right?  I've gotta set up the environment for Eclipse.

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



Well done!

This is an incredibly important line of development for JME3. This opens up a whole new market for us both in terms of users and prospective developers. I think with the ability to market JME as an 'Android Engine', we can easily spur up a lot of attention.


normen said:

ashtonv said:

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!

There is no plans to use com.jme or com.jmex packages since the new jme3 is quite a different beast than version 1.0/2.0.
Probably the g3d package is here to stay.
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.

Are any of you guys familiar with Motodev? Probably worth checking out by now :)
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.
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..
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.
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..




well why not com.jme3 wouldn't that serve to distinguish itself and maintain "branding consistency" all at the same time, even with "free" software, business marketing for thought goes a long ways in selling what u'r selling............NO?

Sorry, but "com.jme" isn't possible because people who want to use both jme2 and jme3 in the same project will have problems (for reasons of model conversion for example). Anything but "com.jme" is fine though, even "org.jme"…

It goes against convention, but com.jme3 is a possibility.

Momoko_Fan said:

Sorry, but "com.jme" isn't possible because people who want to use both jme2 and jme3 in the same project will have problems (for reasons of model conversion for example). Anything but "com.jme" is fine though, even "org.jme"..


Hm.  I'm not sure what to make of this -- I was thinking that jME 3.x was going to be self-sufficient, meaning that if any code/functionality (like the model loaders) from jME 2.x was going to be used then it would be formally ported to jME 3.x as a part of the new engine.  Having a patchwork engine/application comprised of 2.x and 3.x  doesn't sound very appealing and seems to somewhat defeat the purpose of a new major version number -- it's jME 3 except where it's still 2!... umm...

Perhaps this calls for some use-cases for everyone's perusal to assess the general mood toward this sort of setup.  I for one would rather have 3 as a self-sufficient engine all under the umbrella of com.jme.
ashtonv said:

Hm.  I'm not sure what to make of this -- I was thinking that jME 3.x was going to be self-sufficient, meaning that if any code/functionality (like the model loaders) from jME 2.x was going to be used then it would be formally ported to jME 3.x as a part of the new engine.  Having a patchwork engine/application comprised of 2.x and 3.x  doesn't sound very appealing and seems to somewhat defeat the purpose of a new major version number -- it's jME 3 except where it's still 2!... umm...

This is not how you should get it. If you start a project with jme3 you will be able to do so without any additions from jme2. It is just that one can already tell that some projects that migrate from jme2 to jme3 might want to use a combination of jme2 and jme3 to build tools to convert their current content.
And maybe some projects want to use some special function of jme2 that did not make its way into jme3 because it was replaced by other functions.