Some newbies questions (before using JME for TUER)

Hi! I'm not a newbies in game programming (9 years) nor in 3D game programming (3 years) neither in 3D Java game programming (2 years) but I have never used JME. I would like to use it instead of my own engine because I think it is time to end my scientific investigations and experimentations, I don't want to rewrite lots of things already implemented in JME. I have several questions for you all:

  • Is JME 2 reliable enough to be used in production phase?
  • Is it still well maintained whereas some original authors have left the project?
  • As far as I know, only one person maintains the JOGL renderer. Can I use it reliably?
  • Is it possible to put a plugin into JME 2 to use only JavaSound and not JOAL?
  • Is it possible to put a plugin into JME 2 to use Java but not JInput for keyboard and mouse handling?
  • Does JME 2 work on low end machines?
  • Does it work where VBO are not supported? (Can it use ARB VBO?)
  • As far as I know, JME doesn't implement the cells-and-portals algorithm. Is the structure of JME 2 flexible enough to add it?
  • Does JME 2 work under OpenJDK? Soylatte? Kaffe? under Solaris?
  • Does JME 2 only rely on quaternions to solve the problem of gimbal lock?
  • Is it possible to precompute a finite count of interpolations rather than doing it in real time when using MD3 models in JME 2?



    My main aim is to improve my game and I know that I will have to improve the reliability of the JOGL renderer as I plan to use it. I don't want to suffer from bugs of JInput and JOAL because I'm sure I don't need to use these libraries. Some original authors refused my help 2 years ago. I hope that things have changed. Thank you for reading.
  • Is JME 2 reliable enough to be used in production phase?



    Yes.


  • Is it still well maintained whereas some original authors have left the project?



    There are plenty of people doing patches and such, aside from that it is pretty stable already.


  • As far as I know, only one person maintains the JOGL renderer. Can I use it reliably?



    LWJGL is much better supported at the moment.


  • Is it possible to put a plugin into JME 2 to use only JavaSound and not JOAL?



    The sound framework is pluggable, so you could write a JavaSound implementation. You can also use Javasound directly if you want. (Of course JavaSound is not that good)


  • Is it possible to put a plugin into JME 2 to use Java but not JInput for keyboard and mouse handling?



    JInput is only used for input from Joysticks and gamepads and such. LWJGL handles all other input. Not sure how it's done for JOGL though…


  • Does JME 2 work on low end machines?



    Yes. OpenGL 1.2 is the minimum requirment.


  • Does it work where VBO are not supported? (Can it use ARB VBO?)



    It uses only ARB afaik, check the source code to be sure though. It does check if it's supported first too…


  • As far as I know, JME doesn't implement the cells-and-portals algorithm. Is the structure of JME 2 flexible enough to add it?



    People have done portal implementations for jME before (including quake map loading and such). However noone ever "finished" there implementation enough to put it in jME. It shows it can be done I guess.


  • Does JME 2 work under OpenJDK? Soylatte? Kaffe? under Solaris?



    OpenJDK is more or less Java 7, so that should work. Soylatte still does not have a non-X11 AWT (and OpenGL inside X11 doesn't work in OSX afaik). AWT is used on OSX by LWJGL for doing some stuff like discovering display resolutions. JOGL obviously needs it too.



    As for Kaffe and Solaris feel free to try. In general you'll need OpenGL support, and on top of that LWJGL support, then jME should work.


  • Does JME 2 only rely on quaternions to solve the problem of gimbal lock?



    JME support Quaternions.


  • Is it possible to precompute a finite count of interpolations rather than doing it in real time when using MD3 models in JME 2?



    Well, someone will have to take that one… I don't think so. Shouldn't be hard to add I guess (basically you'll just create a whole bunch of vertex buffers in advance?)
  • Is it possible to precompute a finite count of interpolations rather than doing it in real time when using MD3 models in JME 2?



    i guess you mean interpolation between the keyframes of md3-animations? i am currently using md3 animated models quite extensively. my artist provides models with keyframes at fixed intervals. so if you have the knowledge of where in the animation the keyframes are and you update the animation to exactly that point in time, jme won't interpolate between keyframes but will just draw a series of geometries. (but why would you want to use animated md3 models then?)



    if i understood you wrong, just ignore the post  :wink:

Good idea, I guess that there are tools that can export your animation as only keyframes?



But that would make the model much bigger…

- Does JME 2 work on low end machines?

Yes. OpenGL 1.2 is the minimum requirment.



It's working, but without a good graphic card you lose.
I tried to use jME with an normal onboard graphic card.
The Speed was at best 0-3 Frames per Second.

At least you need any Ati or Nvidia Graphiccard!
If you want to use Shaders, then it depends on your graphic card.

CPU and RAM shouldn't be any problem

Well that depends on what you do obviously.



I use jME on my Intel X3100 on board graphics (Macbook white, rev 4). Works just fine for a lot of stuff.

DarkPhoenixX said:

- Does JME 2 work on low end machines?

Yes. OpenGL 1.2 is the minimum requirment.



It's working, but without a good graphic card you lose.
I tried to use jME with an normal onboard graphic card.
The Speed was at best 0-3 Frames per Second.

At least you need any Ati or Nvidia Graphiccard!
If you want to use Shaders, then it depends on your graphic card.

CPU and RAM shouldn't be any problem


The whole hardware configuration has to match with what you want to do with jME. my laptop has a ATI mobility 9700 (nearly 5 years old) and tackles more than 10.000 vertices with textures on them and a few minor animations with good framerates (30-60). That is mainly because texturing isn't something new and older cards do that just fine as well and Geometries and animations are calculated on CPU.

On the other hand i tried an application with a reflecting floor (shader) and TWO quads that were on top of it and to be reflected. that makes 12 vertices and one shader on a slightly bigger quad. ... FPS < 1  ;)

Some of the newer integrated Intel chips are pretty good with shaders even. They certainly push more than 10.000@60 fps vertex too.



http://www.youtube.com/watch?v=PHn2ZIFGwPg&feature=related (and the related vids in there too)



Certainly won't be displeased if jME games will look like that on my laptop…

dhdd said:

DarkPhoenixX said:

- Does JME 2 work on low end machines?

Yes. OpenGL 1.2 is the minimum requirment.



It's working, but without a good graphic card you lose.
I tried to use jME with an normal onboard graphic card.
The Speed was at best 0-3 Frames per Second.

At least you need any Ati or Nvidia Graphiccard!
If you want to use Shaders, then it depends on your graphic card.

CPU and RAM shouldn't be any problem


The whole hardware configuration has to match with what you want to do with jME. my laptop has a ATI mobility 9700 (nearly 5 years old) and tackles more than 10.000 vertices with textures on them and a few minor animations with good framerates (30-60). That is mainly because texturing isn't something new and older cards do that just fine as well and Geometries and animations are calculated on CPU.

On the other hand i tried an application with a reflecting floor (shader) and TWO quads that were on top of it and to be reflected. that makes 12 vertices and one shader on a slightly bigger quad. ... FPS < 1  ;)

The current engine of TUER displays about 1 000 000 textured quads with about 14/28 FPS with an ATI Radeon 9250 Pro. I use VBO when available. Is it possible to have the same frame rate with JME with such a geometry?

in my application the framerate is never the problem, but the java heap space is always running out of memory, and if i increase the heapspace, the main memory is runnin gout of memory :smiley:

screens shots here (matrix spirit) : http://www.jmonkeyengine.com/jmeforum/index.php?topic=9666.0

perform at 25frames/sec on a mother board integrated 6150 nvidia card (without shaders)

kine said:

screens shots here (matrix spirit) : http://www.jmonkeyengine.com/jmeforum/index.php?topic=9666.0
perform at 25frames/sec on a mother board integrated 6150 nvidia card (without shaders)

Nice screenshots :) How much polygons are displayed?

I have launched jmetest.util.JMEJOGLAWTTest and I get this:

[java] INFO: reshape com.jmex.awt.jogl.JOGLAWTCanvas[canvas0,0,0,640x480], 0, 0, 640, 480

    [java] Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException

    [java]    at com.jmex.awt.jogl.JOGLAWTCanvas.reshape(JOGLAWTCanvas.java:217)

    [java]    at com.sun.opengl.impl.GLDrawableHelper.reshape(GLDrawableHelper.java:85)

    [java]    at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:431)

    [java]    at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)

    [java]    at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)

    [java]    at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)

    [java]    at javax.media.opengl.GLCanvas.paint(GLCanvas.java:277)

    [java]    at com.jmex.awt.jogl.JOGLAWTCanvas.paint(JOGLAWTCanvas.java:223)

    [java]    at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)

    [java]    at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:56)

    [java]    at sun.awt.RepaintArea.paint(RepaintArea.java:224)

    [java]    at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:683)

    [java]    at java.awt.Component.dispatchEventImpl(Component.java:4489)

    [java]    at java.awt.Component.dispatchEvent(Component.java:4243)

    [java]    at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)

    [java]    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)

    [java]    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)

    [java]    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)

    [java]    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)

    [java]    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)

    [java]    at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)



Is it a joke?  :? Is it a good sample of the possibility of JOGL in JME??? I'm disappointed.

Where is the documentation for com.jme.system.jogl.JOGLDisplaySystem??? When I look at http://www.jmonkeyengine.com/doc, I don't find it. I'm becoming really sad  :(  :x

That's jME 1 documentation. As said before LWJGL is much and much more mature. Any reason not to use LWJGL?

llama said:

That's jME 1 documentation. As said before LWJGL is much and much more mature. Any reason not to use LWJGL?

There is a kind of progress:
[java] Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: glGetError() returned the following error codes after a call to glGetIntegerv(): GL_INVALID_ENUM
    [java]    at javax.media.opengl.DebugGL.checkGLGetError(DebugGL.java:12715)
    [java]    at javax.media.opengl.DebugGL.glGetIntegerv(DebugGL.java:3371)
    [java]    at com.jme.renderer.jogl.JOGLContextCapabilities.init(JOGLContextCapabilities.java:187)
    [java]    at com.jme.renderer.jogl.JOGLContextCapabilities.<init>(JOGLContextCapabilities.java:147)
    [java]    at com.jme.system.jogl.JOGLDisplaySystem.initForCanvas(JOGLDisplaySystem.java:438)
    [java]    at com.jmex.awt.jogl.JOGLAWTCanvas.init(JOGLAWTCanvas.java:156)
    [java]    at com.sun.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:72)
    [java]    at javax.media.opengl.GLCanvas$InitAction.run(GLCanvas.java:418)
    [java]    at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:189)
    [java]    at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)
    [java]    at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
    [java]    at javax.media.opengl.GLCanvas.paint(GLCanvas.java:277)
    [java]    at com.jmex.awt.jogl.JOGLAWTCanvas.paint(JOGLAWTCanvas.java:222)
    [java]    at sun.awt.RepaintArea.paintComponent(RepaintArea.java:248)
    [java]    at sun.awt.X11.XRepaintArea.paintComponent(XRepaintArea.java:56)
    [java]    at sun.awt.RepaintArea.paint(RepaintArea.java:224)
    [java]    at sun.awt.X11.XComponentPeer.handleEvent(XComponentPeer.java:683)
    [java]    at java.awt.Component.dispatchEventImpl(Component.java:4489)
    [java]    at java.awt.Component.dispatchEvent(Component.java:4243)
    [java]    at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
    [java]    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
    [java]    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
    [java]    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
    [java]    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
    [java]    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
    [java]    at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

display() is called before init(), it is a strange behavior. I will NEVER use LWJGL to port TUER on JME. TUER has been written with JOGL that has proven to be very reliable, used for professional engines (Aviatrix3D for example). I like the job Kenneth Russell has done on it. In JOGL, 150 lines of C code fix some bugs under Windows and the GLU rewritten in pure Java allows to avoid bugs of the native GLU under some Linux versions. Some people who use TUER are under Solaris and lots of people use TUER under Linux. I have used JOGL for 2 years, I won't give up now. I only need a reliable OpenGL binding, I don't need JInput and JOAL, why would I use LWJGL whereas JOGL is at least as reliable as LWJGL? I don't want to suffer of local bugs of OpenAL. When I tried some games using Java3D and JOAL (for example Arabian Nights), I had to install the development packet to make it work!!! Which normal users would be able to do this?

To fix the JOGL test, I think I have to remove some invalid things.

LOL, well LWJGL relies on neither JOAL nor JInput nor GLU. None of these libraries have anything to do with LWJGL (I think the GLU stuff is all pure Java in LWJGL these days). jME doesn't use any of these either except JInput, but again only for game controllers (afaik I don't know any other java library that supports these, so for JOGL you'll still have to use that if you want to support controllers, or roll your own code).



The reason that JOGL is not so well supported is that it doesn't have any real advantage over LWJGL for must users (all the arguments you list in favor of JOGL apply to LWJGL too), and jME just happened to use LWJGL (which up to a year or 2 ago was the only serious option for making games in Java).



That said, if you're such an expert in JOGL I can see you'd want to keep using that. We could sure use some extra hands bringing the JOGL code up to the level of LWJGL… considering the two are almost interexchangeble it's probably not even that much work, more a question of people such as yourself making active use of it and fixing bugs.


IT works now!!!  :smiley: :smiley: :smiley:



JOGLAWTCanvas repaired  :smiley:



Hey guys, rely on me! JOGL rocks.

:smiley:

The cube is pretty :slight_smile: How can I submit my fixes now?