jMonkeyEngine PROS and CONS survey (27 posts)

  • Profile picture of erlend_sh erlend_sh132p said 2 years, 8 months ago:

    The 2.0 stable will be upon us this Sunday, marking the beginning of the road ahead to v2.1. In relation with this progress I would like to ask the community to partake in a 3-part survey, that aims to benefit both JME 2&3 (2nd part will only reflect on 2.0 and 3rd part will largely be 3.0 only).

    The Three Parts

    1. Pros and cons of JME 2.0
    2. Feature requests for 3.0
    3. Feature rankings

    I sincerely hope we will get to see a large portion of the community partake in this three-part survey. This is a unique opportunity to be a part of the few focus points that can be afforded for 2.x development. For 3.0 you get to directly influence the priorities of the core developers, and maybe even open their eyes to a neglected golden feature.

    See the thread below for the first part in this survey.

    Rating
  • Profile picture of erlend_sh erlend_sh132p said 2 years, 8 months ago:

    Make a simple list of pros and cons for JME. It can be a specific aspect or a memorable experience. It's up to you whether you want to get into the technicalities, the practicalities or both.

    - Write down 2-5 one-liners detailing your favorite features or memorable positive experiences with the Java Monkey Engine.
    - Write down 2-5 one-liners detailing the exact opposite of the above.
    - Post it here!

    Technical examples:

    Pro
    "The greatest was when I implemented JOPS rendering in jME. I just did it, and it was fast as a motherf****r. Great, cause I had learned jME enough to actually make something usable and reusable for it, with great performance."

    Con
    "Every time I find myself searching for that bloody object I just put in the game and it just won’t show up. Usually I just forgot to call updateRenderStates() , we’ve all been there. Don’t deny it."

    Practical examples:

    Pro
    "It's free!"

    Con
    "Project lacks strong direction"

    Rating
  • Profile picture of duenez duenez said 2 years, 8 months ago:

    Hmmm, I cannot believe I am the first to reply here… Oh well, I hope I don't stand out for my ignorance  :wink:

    Pros

    Clear unified base-code (featuring Java 5 style consistently)
    JOGL/LWJGL option for rendering and render-independent JME file formats
    Support for Ogre3D format
    Nice and shinny new stats display

    Cons

    Still lacking documentation and wiki pages specific to 2.0
    Too directly based on jME 1.0 (needs new direction? 3.0?)
    The always pervasive artwork pipeline problem. No easy way to import arbitrary models with animations
    More features would be nice… like better shadows, or more post-processing shaders and the like

    Hope this helps!  :roll:

    Rating
  • Profile picture of erlend_sh erlend_sh132p said 2 years, 8 months ago:

    duenez said:
    Hmmm, I cannot believe I am the first to reply here…

    I must admit I was surprised myself… I imagined this a welcomed opportunity for some inspired ranting in between JME waltz & wrestling sessions ;D

    This sure helps duenez! I see your comments are a mix of technical and practical (i.e. administrative) which I forgot to mention is absolutely welcome.

    By "Too directly based on jME 1.0" I suppose you're referring to the documentation. Anything else that still points in that old worn out direction though?

    Rating
  • Profile picture of dhdd dhdd2p said 2 years, 8 months ago:

    Pros:
    – its free
    – its Java
    – it works

    Cons:
    – artwork pipeline is a pain in the backside

    Rating
  • Profile picture of gouessej gouessej-2p said 2 years, 8 months ago:

    Pros:
    (I agree with dhdd)
    - free
    - open source
    - written in Java
    - quite reliable (but it could be better)
    - lots of interesting features
    - faster than the other 3D engines
    - hardware acceleration

    Cons:
    - there is a real lack of optimisation for GPU-limited computers
    - the JOGL renderer (:() is not as reliable as it should
    - it is still not possible to use it with Android (if I take only the standard stable version)
    - there is not yet any fallback on JavaSound whereas unfortunately OpenAL works badly on a few machines (but 3D sound system should solve this problem)
    - no commercial support
    - not enough documentation
    - the wiki is not up-to-date
    - no official example using JOGL
    - it uses JOGL 1.1.1 whereas JOGL 2.0 is available
    - it would be fine to have a RAD tool, something like Shiva
    - there is no way of converting the source code of a game using JME into C#/XNA source code (to target XBox 360)
    - it is very difficult (but not impossible) to buid a collision system without JME Physics whereas some games do not need a so complicated physic engine

    Rating
  • Profile picture of Alric Alric1p said 2 years, 8 months ago:

    I suspect the thread title might be causing some confusion, at a glance on the front page I assumed it was a thread about monochrome rendering  :|

    Disclaimer: Hopefully this is a constructive list for the betterment of JME. I base it on my experience working with jME and what I think would be ideal or some app that does something well. Not necessarily Java or even a game engine (examples Unity, GROME, DAZ). ie the criticism isn't relative to something else – obviously, jME is good :)

    Pros

    For a Java coder, JME makes it quick to start working with 3D and using many advanced features. Saves a huge amount of time compared to using lower level libraries directly.
    Able to produce very nice games, demos and apps with good graphics and performance. No showstoppers.
    Fairly straightforward to add features. Few limits to what you can do if you are prepared to implement some algorithms yourself.
    Doesn't dictate how you code. Design, structure and code your app in your preferred way using any Java methods and API's.
    The API is generally easy to work with.
    The community is generally friendly and helpful for the competent beginner to intermedate developer. The forum history forms a pretty good set of documentation for many common problems.
    Source code is generally easy to understand and modify.
    Decent performance, ability to implement your own case-specific optimisations (albeit because JME doesn't

    Cons

    Lack of emphasis on the engine's ability to help you produce finished, polished games or apps.
    Resource management is very poor.
    Critical features left below par and/or out of date and/or outside the core (sound, gui, physics, animation, splatting etc etc.)
    Lacks game engine features, such as spatial partitioning, scripting, terrain handling, foliage.
    Lacks tools support.
    Lacks advanced graphical effects, poor shader support (presume JME 3 to remedy this).
    Things (features, tools) too often don't get into the core project, and miss the benefits of open source software as a consequence.
    Lack if stuff to show off the engine that will really impress. Most of what there is developed in isolation and often screenshots or video only. Reflects the engine itself as per the above.

    Feature requests

    Much improved resource and memory management (textures, sounds in particular). Threaded loading.
    Redo the soud system or integrate another one.
    Integrate key tools into the core like the particle editor is. Examples, a scene editor, model/entity/character importer/editor.
    Make very common effects such as texture splatting and bump mapping, very easy to add with only core code.
    Won't just rewrite my cons list!

    Rating
  • Profile picture of MikOfClassX MikOfClassX2p said 2 years, 8 months ago:

    Pros:
    - its free/opensource/Java
    - it is supported by a great community
    - the questions in the forums often receive interesting/helpful answers from both jme developers and users
    - has good support for model loading
    - delivers very good performance
    - meets common 3D gaming needs

    Cons:
    - no context sharing support (i.e. initializing JME from an existing GL context)
    - too much static references around (Display,DisplaySystem)
    - has JOGL support, but who really needs it ? LWJGL is exactly what we need for JME, so let's save time..
    - there's always the need to update() the scenegraph/states in order to apply changes.
    - render to texture api could be better (i.e. tr = new TextureRenderer(node) , tr.asTexture(), tr. update())

    Cheers,

    Mik

    Rating
  • Profile picture of mcbeth mcbeth19p said 2 years, 8 months ago:

    MikOfClassX said:
    Pros:
    - its free/opensource/Java
    - it is supported by a great community
    - the questions in the forums often receive interesting/helpful answers from both jme developers and users
    - has good support for model loading
    - delivers very good performance
    - meets common 3D gaming needs

    Cons:
    - no context sharing support (i.e. initializing JME from an existing GL context)
    - too much static references around (Display,DisplaySystem)
    - has JOGL support, but who really needs it ? LWJGL is exactly what we need for JME, so let's save time..
    - there's always the need to update() the scenegraph/states in order to apply changes.
    - render to texture api could be better (i.e. tr = new TextureRenderer(node) , tr.asTexture(), tr. update())

    Cheers,

    Mik

    now why did u have to go and that……………….no really…………….hopefully he'll just ignore it

    Rating
  • Profile picture of erlend_sh erlend_sh132p said 2 years, 8 months ago:

    mcbeth said:
    now why did u have to go and that

    He is entitled to his own opinion. Seeing as that is what this thread is all about, and not actually argument for or against any bullet points mentioned at this time, I hope everyone will respect this and merely use others' comments as reference and comparison; not to start any arguments.

    Rating
  • Profile picture of MikOfClassX MikOfClassX2p said 2 years, 8 months ago:

    I'm not going to flame about JOGL support (and by NO means I want to insult someone, it's just my opinion, ok ?).

    My opinion about JOGL is far from being bad. The existence of JOGL itself is really important for the java community.

    Coming back to JME, yes, we have a choice, but which is the GL backend developers are using now if they want to ship a reliable application ? LWJGL.

    I think that maintaining (developing/testing/supporting) 2 different backends is not a joke, that's why I would first concentrate the development resources to other important things: features, stabilty, documentation.

    Rating
  • Profile picture of gouessej gouessej-2p said 2 years, 8 months ago:

    MikOfClassX said:
    - has JOGL support, but who really needs it ? LWJGL is exactly what we need for JME, so let's save time..

    It is really an insult, I'm fed up! It is too late! JOGL is inside JMonkeyEngine, it cannot be abandoned. If nobody needed it, it would not be supported by JME 2. I'm really angry, I've spent a lot of time (and money) in trying to drive the JOGL renderer more reliable. You're happy with LWJGL like lots of JME 2 users, that is fine, but some people including me need JOGL. I won't turn this thread into JOGL versus LWJGL debate.

    Rating
  • Profile picture of sbook sbook255p said 2 years, 8 months ago:

    PRO's
    - Open Source & Java
    - The Wiki + Forum serve as a kind of master handbook.  A ton of questions have been asked, a ton have been answered.
    - Very helpful community for beginners and veterans alike.
    - Active development is back in swing.

    CON's
    - A lot of these side projects for terrain, morphing, animation support, etc are close to prime time for putting into the engine.  We need to make sure that they find their way into the dev branch if the authors are open to it.
    - For all that the forums and wiki have, documentation is still lackluster for some parts.  This is usually as it pertains to integrating third party code extensions.  Having them integrated as I mentioned would certainly help this point.
    - As lawnmower mentioned, needs artists to produce sharp looking 'marketing' materials.
    - Simplified art pipeline so more time is spent on making well-built games.  Good looking should be left to the artists ;)

    Rating
  • Profile picture of mcbeth mcbeth19p said 2 years, 8 months ago:

    erlend_sh said:

    mcbeth said:
    now why did u have to go and that

    He is entitled to his own opinion. Seeing as that is what this thread is all about, and not actually argument for or against any bullet points mentioned at this time, I hope everyone will respect this and merely use others' comments as reference and comparison; not to start any arguments.

    yes but in the context of thread it seemed an unneccessary nitpickthan an actual con………… the right to ones opinion not withstanding, especially given the angered nature of one of the posts that came after

    Rating
  • Profile picture of duenez duenez said 2 years, 8 months ago:

    People, please… let's keep it civilized. I am willing to give MikOfClassX the benefit of the doubt that he was really trying to be playful by saying that nobody needs JOGL because he doesn't use it, and knows of nobody who does. I think that is why I would take macbeth's reply as a simple continuation on the playfulness.

    @gouessej I remember back a while ago I went on vacation for a summer, and stayed out of touch with jME for a while, and then I returned to see there was JOGL support. I think even if people don't activley use JOGL, it helps developers think of how to abstract and decouple better the rendering engine, which is always good to do IMHO.

    edit: fixed typo

    Rating