What kind of texture format are you trying to load?
normen said:
What kind of texture format are you trying to load?
I use the TextBox example, it loads a PNG file somewhere...
Why is there a call of GeoTools?
Hm, no idea. I have the package on my mac standard java install… Dont know if its actually used when loading png’s… Do you use the oracle java vm or some open source version?
Ok it comes from my environment, a JAR coming from GeoTools is somewhere in my workspace and it tries to call JAI.
I am guessing your Java VM uses JAI and its assorted plugins instead of using the OS to load the images. This would explain the issue.
Ok I have this now, I’m going to fix it:
Caused by: java.lang.NullPointerException
[java] at com.jme3.material.Material.setTexture(Material.java:320)
[java] at jme3test.model.shape.TestBox.simpleInitApp(TestBox.java:58)
[java] at com.jme3.app.SimpleApplication.initialize(SimpleApplication.java:187)
[java] at com.jme3.system.jogl.JoglDisplay.init(JoglDisplay.java:204)
[java] at com.jogamp.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:113)
[java] at com.jogamp.opengl.impl.GLDrawableHelper.init(GLDrawableHelper.java:126)
[java] at javax.media.opengl.awt.GLCanvas$InitAction.run(GLCanvas.java:646)
[java] at com.jogamp.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:284)
[java] at javax.media.opengl.awt.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:677)
[java] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
[java] at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
[java] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
[java] at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
[java] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
[java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
[java] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
[java] at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Ok it works. It creates a tiny window that I cannot resize but it works 
Very cool. Glad you got it working.
Some changes will need to be made to the material system to fully support OpenGL1 though.
Hi!
Momoko_Fan said:
Very cool. Glad you got it working.
Some changes will need to be made to the material system to fully support OpenGL1 though.
Ok.
I still have a tiny window (30 * 30) whereas I do this:
[java]public static void main(String[] args){
TestBox app = new TestBox();
app.setShowSettings(false);
AppSettings settings = new AppSettings(false);
settings.setAudioRenderer(null);
settings.setRenderer("JOGL");
settings.setWidth(800);
settings.setHeight(600);
settings.setResolution(800, 600);
app.setSettings(settings);
app.start();
}
}[/java]
The first time, it works correctly and after that, I get a tiny window.
Ok I’ve fixed this bug, pack was called in JoglCanvas. Where can I submit all this source code? Can someone create a branch for this or would you like this renderer to expend the current JOGL renderer?
Ok TestNiftyGui works fine
Cool, you can commit it to the jme3 branch directly, simply add the sources under “/src/jogl2” and add the libraries under “/lib/jogl2” then we can add it to the project and natives.jar etc.
Edit: So yeah, I guess we will simply replace it, so no worries about package names etc.
Ok I’ll do it tomorrow evening (French time) as I have some problems with SVN here, I can do it only at home.
https ports blocked at work? or did you checkout via http? then its not so easy to switch to the https version, depends on your svn client. easiest way would be checking out via https again. just some random ideas ^^
Cheers,
Normen
Cool stuff! So, where will this project go from here? Are you done for your part already? Is there anything jME3 with JOGL2 can or can’t do as opposed to LWJGL?
Hi!
erlend_sh said:
Cool stuff! So, where will this project go from here? Are you done for your part already? Is there anything jME3 with JOGL2 can or can't do as opposed to LWJGL?
Sven has recently fixed the most impacting remaining bug of JOGL 2, that means that switching to this version is becoming a really safe option. Performing this switch when the next autobuild is available would be fine.
My part is not done, the JOGL renderer that I modified is more reliable, the previous one was immediately crashing (because of NullPointerException in JoglRenderer in lots of methods) and seriously broken. My fixes are useful for the JOGL renderer using JOGL 1.1.1a too. JOGL 2.0 can do the same things than the LWJGL part dealing with windowing and OpenGL (and even more as the OpenGL-ES access is homogeneous and fully integrated in JOGL 2.0) but the current JOGL renderer of JMonkeyEngine 3 does not support materials correctly on low end hardware (I looked at the material files but I have not yet tested it on a low end machine).
NiftyGUI is excellent but you have chosen an API that has only a LWJGL renderer and a Java2D renderer but no JOGL renderer. Sorry but it is not fair. I understand that JMonkeyEngine is a community project like JogAmp (JOGL + JOCL + JOAL + Java binding for OpenMAX) but choosing a GUI API that relies on LWJGL whereas JMonkeyEngine is intended to be used with JOGL too is a bad signal sent to the JogAmp community. It means that the support of JOGL is once more the "poor parent" of the JMonkeyEngine project. Having a poor support of JOGL in JMonkeyEngine is pretty bad for JOGL, not for JMonkeyEngine. Maybe I will have to write a JOGL renderer for NiftyGUI :(
I get this when I launch TestNiftyToMesh :
Exception in thread "Timer-0" javax.media.opengl.GLException: java.lang.NullPointerException
at com.jogamp.opengl.impl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:101)
at com.jogamp.opengl.impl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:192)
at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:164)
at javax.media.opengl.awt.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:594)
at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:302)
at com.jogamp.opengl.util.AnimatorImpl.display(AnimatorImpl.java:51)
at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:99)
at com.jogamp.opengl.util.FPSAnimator$1.run(FPSAnimator.java:109)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.NullPointerException
at com.jme3.texture.Image.getData(Image.java:452)
at com.jme3.renderer.jogl.TextureUtil.uploadTexture(TextureUtil.java:78)
at com.jme3.renderer.jogl.JoglRenderer.updateTextureData(JoglRenderer.java:555)
at com.jme3.renderer.jogl.JoglRenderer.setTexture(JoglRenderer.java:575)
at com.jme3.material.Material.render(Material.java:636)
at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:372)
at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:132)
at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:179)
at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:505)
at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:485)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:647)
at com.jme3.renderer.RenderManager.render(RenderManager.java:667)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:217)
at com.jme3.system.jogl.JoglDisplay.display(JoglDisplay.java:304)
at com.jogamp.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:140)
at javax.media.opengl.awt.GLCanvas$DisplayAction.run(GLCanvas.java:660)
at com.jogamp.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:291)
at javax.media.opengl.awt.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:677)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
I'm investigating. I think that some modifications in the LWJGL renderer have not been reflected in the JOGL renderer, I have to confirm this.
Edit.: setShader() is not implemented in the JOGL renderer :(
Edit2.: setFrameBuffer() is not implemented too in the JOGL renderer, that is why the exception above is thrown :(
TextureUtil in the JOGL renderer did not contain one of the fix put into its LWJGL equivalent (the first occurrence of “&&”):
[java]public static void uploadTexture(GL gl, Image img, int index, boolean generateMips,
boolean powerOf2) {
Image.Format fmt = img.getFormat();
ByteBuffer data;
if (index >= 0 && img.getData() != null && img.getData().size() > 0) {
data = img.getData(index);
}
else {
data = null;
}[/java]
The JOGL renderer was completely abandoned, wasn’t it?
The JOGL renderer was completely abandoned, yes. The biggest flaw of jME2 was that it tried to incorporate every little contribution and extension resulting in a mess of possible combinations that lead to a system that was only usable after doing extensive research trying all combinations. We try to avoid that in jME3 and frankly, we were thinking about dropping JOGL support for Desktop completely and just (maybe) using JOGL for the android renderer (or write a new renderer specifically for android). Also I think you cannot talk about “fairness” when we do or dont implement a renderer system or GUI system that has support for a specific renderer. We only try to create a complete system for game development that works. Its open source, so everybody can do whatever he wants to with it, I think thats “fair enough”. But the package we deliver should just work and so we only want to include things we know we can and will extend, improve and fix.
Cheers,
Normen
Edit: @Momoko_Fan wrote a jME3 renderer specifically for Nifty, it does not use the nifty LWJGL renderer afaik. It uses jME3 Quads etc.
1 Like
gouessej said:At the time we "chose" NiftyGUI, JOGL was pretty much at an abandoned state. Apart from that, Nifty worked almost straight out of the box with jME3 from the start, it looked great and to this day it is being actively developed by a dedicated core developer and a committed group of contributors. On top of that the author, Jens "void", was very forthcoming and happy to collaborate directly with us. All of that put together was much more valuable, to us as well as our users, than what JOGL-compatibility would have meant back then.
NiftyGUI is excellent but you have chosen an API that has only a LWJGL renderer and a Java2D renderer but no JOGL renderer. Sorry but it is not fair.
JOGL2 is now on the rise, which is fantastic. We can only hope that means either a powerful JOGL-compatible GUI library emerges with willingness to collaborate with us, or the Nifty project and its contributors sees enough merit in JOGL to make a renderer for it.
gouessej said:
The JOGL renderer was completely abandoned, wasn't it?
I might come off harsh, but honestly, why shouldn't it be? When a technology stops developing, why bother?
gouessej said:Let's not convolute this development thread with software politics ;) If you want to discuss the jME project agenda, direction, target audience and so forth, your feedback would be very welcome and I would be happy to discuss these issues with you at length. But in this thread, try not to read further into the code than the practical problems it presents in its current state.
I understand that JMonkeyEngine is a community project like JogAmp (JOGL + JOCL + JOAL + Java binding for OpenMAX) but choosing a GUI API that relies on LWJGL whereas JMonkeyEngine is intended to be used with JOGL too is a bad signal sent to the JogAmp community. It means that the support of JOGL is once more the "poor parent" of the JMonkeyEngine project. Having a poor support of JOGL in JMonkeyEngine is pretty bad for JOGL, not for JMonkeyEngine. Maybe I will have to write a JOGL renderer for NiftyGUI :(
erlend_sh said:
At the time we "chose" NiftyGUI, JOGL was pretty much at an abandoned state.
JOGL has never been at abandoned state. I remind you that the NASA has used it for years like several major public and private organizations. The FUD campaigns of a few people seem to be efficient.
normen said:
The JOGL renderer was completely abandoned, yes. The biggest flaw of jME2 was that it tried to incorporate every little contribution and extension resulting in a mess of possible combinations that lead to a system that was only usable after doing extensive research trying all combinations. We try to avoid that in jME3 and frankly, we were thinking about dropping JOGL support for Desktop completely and just (maybe) using JOGL for the android renderer (or write a new renderer specifically for android). Also I think you cannot talk about "fairness" when we do or dont implement a renderer system or GUI system that has support for a specific renderer. We only try to create a complete system for game development that works. Its open source, so everybody can do whatever he wants to with it, I think thats "fair enough". But the package we deliver should just work and so we only want to include things we know we can and will extend, improve and fix.
Ok so drop JOGL support or do it correctly. The problem is that one of the biggest flaw of JMonkeyEngine 2 was that it was written only with LWJGL in mind. A part of the source code contained in packages that are specific to each renderer could have been put into common classes (especially texture handling) so that the whole would be easier to maintain as it has been done successfully in Ardor3D.
normen said:
Edit: @Momoko_Fan wrote a jME3 renderer specifically for Nifty, it does not use the nifty LWJGL renderer afaik. It uses jME3 Quads etc.
I have only a black screen for the moment except with TestNiftyGui.
gouessej said:
JOGL has never been at abandoned state. I remind you that the NASA has used it for years like several major public and private organizations. The FUD campaigns of a few people seem to be efficient.
Ok so drop JOGL support or do it correctly. The problem is that one of the biggest flaw of JMonkeyEngine 2 was that it was written only with LWJGL in mind. A part of the source code contained in packages that are specific to each renderer could have been put into common classes (especially texture handling) so that the whole would be easier to maintain as it has been done successfully in Ardor3D.
I dont exactly think that its a "flaw" to write the renderer only with lwjgl in mind, the flaw would be integrating JOGL after you did :P. As with the physics, supporting a wide range of subsystems will inevitably reduce the potential power of the end system because its the "lowest common denominator" of the subsystems. lwjgl for example supports OpenCL now, if we decided to jump on that train in the future and JOGL does not support it, we're forced to not include the feature just because we used JOGL in the first place (to do something that is working just as well with lwjgl).
jME3 includes JOGL support "traditionally" and its still in alpha, as said, we were and are still thinking about how to handle this. A shiny new and good working JOGL2 implementation might be just the decision helper right now. So all of this is not supposed to be some rant against JOGL, its just explaining why the things are how they are. We want a great game engine, not a great render subsystem frontent.
Cheers,
Normen