This is a somewhat random question… I just want to know what other people need/want from jME3.
At least the Features of jme 1.0.
Wich features is jME 2.0 missing, that jME 1.0 provided?
Did you looked into jME 3 source, dhdd?
It has a much nicer Shader support and it's architecture in general is much nicer to deal with.
Well, there is no multiselecting available but a FAQ / Featurelist would be nice, too.
And maybe a nice Multihreading concept would be nice, too. An Android Renderer would be very nice, though not of that high priority. I sticked into it and it seems to be not many more than providing a limited JOGL Renderer.
Basically what would make me switch is if there is support for a GUI (such as GBUI), physics (like JME Physics), animation (mostly just OgreXML, JMEXML, MD5, etc.), and networking (like JGN). I haven't taken a look at JME3 in a while, so I don't know what's already implemented. 
Ive been looking into porting GBUI to jme3, Ive also got some GBUI enhancements that are pretty good. But I am pretty swamped atm, so cant give an eta, I will probably knock something out nextweek. Physics is something I would like to see in jme3.
SomethingNew said:
Basically what would make me switch is if there is support for a GUI (such as GBUI), physics (like JME Physics), animation (mostly just OgreXML, JMEXML, MD5, etc.), and networking (like JGN). I haven't taken a look at JME3 in a while, so I don't know what's already implemented. ;)
wouldn't mind md5 support, not really sold on the ogre format (character animation based concerns). the animation system seems good though, stuff crashes for me too bur my card might be the issue and I know jme3 is "in development" but maybe it might be a good idea not to "break" the repo, especially since it often seems broken for long stretches..............doesn't really help the marketing effort ;) :D, just imo no offense intended
I would start porting everthing I have (not that I could finish that goal in 2009) if jME 3 supported JOGL's GLJPanel instead of just GLCanvas.
There are a couple of points:
- An official stable, fast and leak-free release.
- All features that are available in jME 1.0.
- New features: Video streaming, stable & fast physics, better sound library (not OpenAL).
- Good overall design, so I don't need a documentation to use it. ( jME 1.0 does this very well. )
once it becomes more powerful than jme 2.0 (hence stable and with more features) then it would just make sense to do the switch.
Momoko_Fan said:
Do you mean, that a JavaSound backend should be available in addition to OpenAL?
Yes, that would be great.
OpenAL-Soft, the dlls which are part of the lwjgl-package, will lead to a crash on some Windows-machines.
I can not recommended to ship these dlls.
It is also not possible to catch the openal-soft-crash as an exception, because it crashes the entire VM.
The only way is to start a small program, that tries to init the sound system. Then you have to check in another program, if the small program failed or not. When it failed, you have to disable the openal-soft-dlls. And THEN you can start your game.
It is better to use the OpenAL installer from Creative Labs.
BUT, some users also have problems (sound glitches) with the original Creative-version. At least it doesn't crash.
In their case it is better, when they use OpenAL-Soft.
All in all: OpenAL is a PITA
If I remember correctly the OpenAL-Soft that comes with LWJGL is quite old, since it doesn't include EFX support. Nevertheless the problems with OpenAL-Soft should be reported to the author rather than ignored, so that they may be fixed. It is actively maintained and crashes are always being fixed.
OpenAL is actually a quite good API otherwise, since it supports advanced 3D sound effects like reverb and occlusion which would be a PITA to implement in JavaSound.
Momoko_Fan said:
better sound library (not OpenAL)
Do you mean, that a JavaSound backend should be available in addition to OpenAL?
For me, the switch to jME3 would be whenever it makes the most sense :p I've been following the development and have been liking the features and thought put into it all. The decision would be part timing with our own projects and when we can 'afford' the time involved to port, as well as the maturity of jME3 at the particular time.
Voted for an official stable release. Switching to the next stable version seems natural to me: considering the fun i'm having with JME 2.0 i can't wait to have the 3.0 in my hands.
Momoko_Fan said:
wouldn't mind md5 support, not really sold on the ogre format (character animation based concerns)
What is the problem with ogre character animation? Is it lack of features on the importer side?
poor wording my bad, work-flow should have been in there, I'm constantly finding issues with my anims and just seems easier to adjust and spit out an md5anim for the individual actions, I can use md5 for testing and may switch to ogre when all actions are finalized though, so no big
The ability to be mostly ThreadSafe would be kinda nice (especially for loading models/textures)
Also a stabe physic integration is essential (especially sine Jme2 now is only short away from one)
Just looking through the jme3 project again, and another thing that might be nice would be a couple of short docs.
Maybe the format of the material's and sometype of syntax info.
An explination of the shader system, and its utility/libary functions.
A package overview, and possibly cleanup(like the bump and oto packages).
While generally its pretty easy to see whats going on by looking. A document would save some time, and help other people develop updates and patches.
Thanks for the replies everyone. I think I have a better idea of what direction I should take jME3 in. Most people seem to be interested in seeing jME3 as a finished product, with documentation, solid features, stability, and at least the features of the older jME versions. Do understand however, that I am a single person working on this, on my spare time, so I might not be able to implement all the things you need in the time you want.
Better/Faster Realtime Collision Detection + Collision Handling in JME 3 + a Stable Release!
It is really incredible what you are doing there all alone. Actually the most important in my oppinion would be to keep the head compilable and to have a working pipeline. I don't know how far you are with animation. I saw that there is an OgreAnimDemo but I couldn't start it because the renderer had some issues. (Which is of course ok, but prevented me from giving jME3 a try)
Once people are able to load their (animated) models and start to use jME3 there might be contributors as well.