I know Im going to get flamed into oblivion for posting this, but this is honest feedback / criticism from an actual user. I want to commend the developers for their efforts so far, I do appreciate the effort.
Some of these issues are cross platform, and some are not the fault of the developers.
So here goes…
Currently, around this site, you see reference to blender to make your models. Blender is great, and you make your models, and then find that you must convert it to either wavefront .obj or ogre .xml.
(Documentation suggestion : just remove the mention to .obj, it is a wild goose chase for new users to look into, as that format does not offer features that you will want, and that ogre has.)
Now you must convert to ogre .xml, so you need a plugin for blender. Well, the one that works, only works for blender 2.4x. 2.5x is very different. So your options are either to downgrade to 2.4 or to try to find an exporter for 2.5. There is one for 2.5 that I know of, and it is being developed outside the official channels. (Outstanding work by that group though, kudos to them, a true study in open source) However, that plugin is unstable, and from my testing, unusable. One example : in the JME IDE (Which is a great tool, by the way… usually) right click the scene or xml that the plugin spits out and convert to j3o. The IDE hangs, forever converting a simple cube to j3o, until you kill the process. (You tied jME to ogre. Either offer more options in this area (support .blend directly plz!) or integrate a converter (.blend->.j3o) as you did with ogre.) The effort it takes to get a mesh into the right format severely outweighs the effort it takes to understand your engine. This should not be! Without meshes, you have nothing.
Usability of the IDE, esp on Ubuntu. For ex : You must not let it update to the nightly build, and you must run with root privileges. These and other Ubuntu issues are well known issues, from what Ive read, but they are a major thorn in an otherwise very cool project. Any timeline on when this will be fixed, or a workaround? Its like having to wipe off the smudge of dirt from your Lamborghinis thumb scanner, but still… 
Things that kinda concern me :
Cryptic Error messages. Example : Would it hurt, when I get a null pointer exception, to tell me the name of the file (or object) involved? Would make path issues just a bit easier to resolve.
Wording in the javadocs. Example : From Material → setTexture : “name - the name of the texture defined in the material definition (j3md) (for example Texture for Lighting.j3md)”. How about “name - Corresponds to a variable in a .j3md material file. For example the variable ‘Texture2D’ is defined in Unshaded.j3md, so specifying name here as ‘Texture2D’ would assign the following parameter (a texture resource) to Texture2D.” Not only is that more clear, you can learn something, and piece the puzzle together a little better.
Observation → Suggestion : The tutorials here are awesome. I think they may be too awesome. There are not many other tutorials I can find on the internet! People think that you have it covered here. Well, you do, mostly, but I suggest encouraging people to submit tutorials of their own on any jMonkey topics. Ideally Id like to see significant overlap, like when you google anything for php. It helps to see it more than one way.
Just a few notes:
re: Ogre… Modern JME3 can read .blend files directly, ie: JME3 newer than alpha4. It’s not great but in many cases it’s at least as good as the ogre transfer and gets better every day. I tried with one of my models after the support was added. The original process was an hour futzing with blender, the ogre export, and the cryptic import process ("Make sure to name all the files the same and include the initials of your first born child, etc.)… and still the poor woman was missing her hair. After updating and getting the .blend support, I was able to take the original .blend file and just open it. Hair was still absent.
re: Cryptic error messages, A NullPointerException is generated by Java and should include the full stack trace. Where are you seeing this message without a stack trace that tells you exactly the file and line the error happened? That would be important information to fixing the problem since every NPE I ever see has that information.
re: Tutorials, I’m not sure how we can encourage that any more than is done. I think most people who are capable of writing good tutorials are probably concentrating on getting their game out the door. And I also suspect PHP has a lot more users than JME… but that’s just a guess.
“Modern JME3 can read .blend files directly, ie: JME3 newer than alpha4.”
From my help → about : (I just updated to most recent build just to test this)
Product Version: jMonkeyPlatform Alpha-4
Java: 1.6.0_20; OpenJDK Client VM 19.0-b09
System: Linux version 2.6.32-33-generic running on i386; UTF-8; en_US (jmonkeyplatform)
Then I created a box5.blend file in blender, (saved the basic cube object you get when you load factory defaults) put it in the right directory, and loaded thusly :
Spatial mybox = assetManager.loadModel(“Models/box5.blend”);
I get, among much else : SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
install jMP, make sure to install the .blend support plugin (I forgot about that when I tried this) and press the green arrow on the menu bar. that’ll let you convert .blend files into .j3o files. you can then load those files directly.
Thanks for the constructive feedback, we are aware that the import process should be easy and simply working but let me remind you that from jME2 to jME3 we already massively improved the situation.
- jME2 “supported” more than ten formats but only one or two really worked to the extend the current importers do (talking about goose chases)
- jME2’s importers would often bring their own animation system (if they even supported animation) which made it much harder to move between formats
- jME2 had no tools to convert and test/prepare models for the game, you would have to find out yourself that creating binary jme files (which most people did) is the best idea to integrate the models in your game.
Most other issues you mention are known and being worked on (e.g. linux bitching about the canvas etc) and those that involve plain time (e.g. elaborate javadoc, documentation, more features) are simply not so easily achievable with only the spare time of us volunteers here
You will certainly find more code examples about PHP than about jME simply because its more wide-spread. If you compare the documentation of the core PHP team and then ours I bet we can be pretty proud of our documentation given that the PHP team can actually pay people to do work.
Cheers,
Normen