Jogl 2

Contribution Depot
41
normen said:
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).

OpenCL is a very bad example as JOGL had got a support of JOCL far before LWJGL. JOCL uses GlueGen like JOGL and JOAL. The "lowest common denominator" of the subsystems is very close to the subsystems themselves especially with JOGL 2 (that has now its own windowing system called NEWT/NativeWindow). LWJGL and JogAmp are now extremely similar except that the OpenAL binding of LWJGL is better maintained than JOAL, JogAmp has a minimal input system (in NEWT) whereas LWJGL relies on JInput.

Bad news: GL.isExtensionAvailable seems to have been broken, I'm going to write a bug report about that.
42

Yes, it might be a bad example but the “own windowing system” might be a good one. :wink:

43
normen said:
Yes, it might be a bad example but the "own windowing system" might be a good one. ;)

AWT has never been a bottleneck when I have developed my own First Person Shooter and as some users might be interested in mixing Swing/AWT/Java2D/JavaFX components with an OpenGL display, handling such an interoperability can be interesting and both renderers need to support it.
44
gouessej said:
some users might be interested in mixing Swing/AWT/Java2D/JavaFX components with an OpenGL display, handling such an interoperability can be interesting and both renderers need to support it.

Exactly my point.
45

normen, can you remind me the URL allowing to checkout JMonkeyEngine 3 with the write access?



When I use this one, I can’t commit anything:

http://jmonkeyengine.googlecode.com/svn/

46

Its the same address, only with the https protocol, so https://jmonkeyengine.googlecode.com/svn/branches/jme3/

47
normen said:
Its the same address, only with the https protocol, so https://jmonkeyengine.googlecode.com/svn/branches/jme3/

Thanks. It seems that I have no more the right to commit or something is wrong. Do I have to use my full email address as a login?
48

Yes it’s your full email address, but be sure it’s the one you registered with.

Btw you are in the committers list http://code.google.com/p/jmonkeyengine/people/list

1 Like
49
nehon said:
Yes it's your full email address, but be sure it's the one you registered with.
Btw you are in the committers list http://code.google.com/p/jmonkeyengine/people/list

It doesn't work even with the full email address :(
50
normen said:
Its your googlecode email and commit password, look in "My Profile"

Thank you very much, I'm stupid. It's done.
1 Like
51

Does JOGL2 use the same binary files and libraries or did you not commit them? It would be cool if you could pack the binaries in a jar file if you forgot, look at the current natives for an example. Let the renderer evaluation begin :wink:

Cheers,

Normen

52
normen said:
Does JOGL2 use the same binary files and libraries or did you not commit them?

JOGL 2 has a noticeably different API than JOGL 1.1.1a. The autobuild is not ready on JogAmp.org and I only have an access to Linux machines. I will commit JARs and native libraries when the autobuild works anew. Is it ok for you?

normen said:
It would be cool if you could pack the binaries in a jar file if you forgot, look at the current natives for an example. Let the renderer evaluation begin ;)
Cheers,
Normen

It is already packed like that. However, the default system that should load the native libraries does not work correctly, I have tested it on several machines using Linux with different OS (Mandriva Linux 2010 & Cent OS 5.3) and different architectures (x86 and amd64).
53

Hi!



Too much things are broken. I will change the architecture as I suggested in another thread so that the both renderers share much code… I still have a black screen on a non trivial example using NiftyGUI.



Edit.: Nifty GUI was not working on non trivial examples because the quad renderer using to render its element interfaces relies on shaders and JoglRenderer.setShader is not yet implemented. I’m going to change this…

54

Everything in jME3 relies on shaders ^^

55
normen said:
Everything in jME3 relies on shaders ^^

It won't be trivial to make it work without them. However, there is so much code duplication, we have to do something.
56
gouessej said:
It won't be trivial to make it work without them.

Its not really supposed to, maybe basic textured materials. Also for OglES we aim at version 2.2, so that includes shader support.
57
normen said:
Its not really supposed to, maybe basic textured materials. Also for OglES we aim at version 2.2, so that includes shader support.

Ok....

Can you tell me what it means? I rarely use shaders, I have no idea of the root cause of this bug:
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_Mode is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_Color is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform g_WorldViewProjectionMatrix is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_Texture is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_ColorMap is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform g_WorldViewProjectionMatrix is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_Texture is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_Color is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform m_VertexColor is not declared in shader.
20 oct. 2010 17:12:24 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
ATTENTION: Uniform g_WorldViewProjectionMatrix is not declared in shader.
58

It looks like you are not supplying the standard jME3 shader variables and do not interpret the shader variables from the material files correctly in your renderer… I dont know exactly how and where its done, maybe @Momoko_Fan can help.

59

Simply converting the OpenGL calls from the LWJGL renderer to JOGL should work fine. You might be incorrectly using the buffers or something. I know JOGL usually takes an int argument specifying buffer length whereas LWJGL does not, specifying that argument incorrectly could lead to the function returning incorrect results.

60

Hi!


Momoko_Fan said:
Simply converting the OpenGL calls from the LWJGL renderer to JOGL should work fine. You might be incorrectly using the buffers or something. I know JOGL usually takes an int argument specifying buffer length whereas LWJGL does not, specifying that argument incorrectly could lead to the function returning incorrect results.

I have submitted the source code of the shader support in the JOGL 2 renderer, maybe you could have a look at it. On my view, it would be easier if each renderer contained only the part of the source code that strictly depends on the underlying API (JOGL, LWJGL), there are too much copy/paste parts, this is a source of mistake too...

Edit.: it comes from setVertexAttrib, I'm going to fix this bug.
Edit.2: it is not enough, there is something else.
Edit.3: I'm changing the whole design, factorizing the source code between the both renderers, it is going to be far better :)