I've spent 3 days converting lwjgl renderer and lwjgl states into jogl. What lefts to be converted? the lwjgl Display System i think thats all.
Few notes
Let me start by saying Jme is awsome, unlike anything i have worked with thus far. They did a good job at seperating lwjgl and Jme
Renderer won't compile because display system isn't converted
States will compile completly but they were easy except for shader related states
I belive my code is unoptimised because ever call to openGL has to go to a GL object so everyfile makes a GL object could probly do with just 1
Display system will have to be completly redone because jogl support awt and swing. This is why i didn't do it because i don't know what you guys want done
Even with display system converted i don't know if it will work all the same,all openGL calls are made, none were removed, but stuff like Pbuffers are handled diffent in Jogl
Sorry to hand you a almost completed project but there are only like 6 files left to convert
As for documentation I left everything the same (authors, and documentation in general) I don't think of myself as a developer so I felt like i shouldn't change anything. Just replaced lwjgl with Jogl
Hey, wakeboardin, thanks for doing this. Badmi also made a conversion a while back and needed to make some DisplaySystem changes himself. I don't think he kept his version current with ours though as I think he left the project in frustration. We weren't quite ready to add JOGL support because we were still changing things a great deal and adding another API requires things to be changed in two places when we make optimizations.
Adding a second rendering API doubles the support we have to do. Since we are a high level API, we tend to fix people's problems with LWJGL as well as jME. So adding JOGL is a big decision. However, maybe we are ready? I'll talk to the other developers about it. In the meantime, it'd be fantastic if you could maintain it for awhile, and maybe get it working (the DisplaySystem changes), until we decide we can support it. I know a lot of people would love you for it.
That being said, why don't you post what you need to figure out with DisplaySystem, and I'm sure you'll get some support.
Good job, that couldn't have been a minor undertaking. Thanks.
I could manage support for jogl. I do need some help on JoglTextureRender because as I said PBuffers are very different in jogl I might look at badmi's code. I would be glad to maintain it but I have a few questions, but I can only think of one now. Where does jme start? Kind of vague but I mean like what is the first lwjgl to be called because then i can save many extra objects if I just make GLCapabilities, GL, and GLU at the start and reuse them. What I hope to be done over the next few weeks and months is convert display system to support awt and maybe swing, set up the logger to receive messages from traceGL and debugGL. In addition, while you are talking to developers about support to jogl, and swing could you also ask about jogl independent features like vender extensions and jogl independent features. I thought on it and first thought Jme would have two books kind of like old Roman law but then concluded that you get the extra features because you went with jogl now lwjgl, which by its name means it, cut down.
where getDisplaySystem is a factory method that compares the getRenderer string and returns the appropriate concrete DisplaySystem. So, in your case, "JOGL" would be sent, and it would return the JoglDisplaySystem class.
Then of course, createWindow (LWJGLDisplaySystem) is called where the following happens:
1. the LWJGL DisplayMode is set, and the LWJGL Display is created.
2. a LWJGLRenderer is created and stored
3. all the default LWJGL Render states are created and stored as the default in Spatial.
Just wondering how does Jme deside on what display system/renderer to go with and I take it the default is lwjgl.
DisplaySystem is given a constant that tells it what to use. So, this constant can be fed directly, or in most cases obtained from PropertiesIO, which is set via the PropertiesDialog.
3: a Pbuffer problem pbuffer.makeCurrent() i don't know what would do the same effect as making the Pbuffer context current. All subsequent OpenGL calls will go to this buffer.
the jogl javadoc reads
gluProject(double objX, double objY, double objZ, double[] model, int model_offset, double[] proj, int proj_offset, int[] view, int view_offset, double[] winPos, int winPos_offset)
as you can see the modelMatrix in lwjgl is float[][] and
jogl is double[] this is also true for projMatrix
also
int model_offset,
int proj_offset,
int veiw_offset,
int winPos_offset
gluUnProject(double winX, double winY, double winZ, double[] model, int model_offset, double[] proj, int proj_offset, int[] view, int view_offset, double[] objPos, int objPos_offset)
gluUnProject(double winX, double winY, double winZ, double[] model, int model_offset, double[] proj, int proj_offset, int[] view, int view_offset, double[] objX, int objX_offset, double[] objY, int objY_offset, double[] objZ, int objZ_offset)
double[] model, double[] proj , int[] view and double[] obj_pos(jogl) besides doubles and floats i need to know what the second matrix is for in modelMatrix, and projMatrix
Got all my work done except those two calls above and inputs it would be a great help. Then i can move on to stuff like GLU tessellation, vendor extensions, and CG(which i personally don't know or am any good at but I like the idea of compiling a shader into a format that works for the card which is only 2 at the time for openGL but in the future this I can see as a make or break technology).
unless somebody figures it out it'll never get done because i've spent 2 days on the same 2 lines of code i'm tried of dealing with it and probly missing something easy
the gluinproject is same parmaters and i set it exactly the same as gluproject model,project,view,result
public Vector3f getScreenCoordinates(Vector3f worldPosition, Vector3f store) {
if (store == null) store = new Vector3f();
// Modelview matrix
FloatBuffer mvBuffer = BufferUtils.newFloatBuffer(16);
gl.glGetFloatv(GL.GL_MODELVIEW_MATRIX, mvBuffer);
double mvArray[] = new double[4*4];
for (int x = 0; x < 4; x++)
for (int y = 0; y < 4; y++)
mvArray[x*4+y] = mvBuffer.get();
// Projection_matrix
FloatBuffer prBuffer = BufferUtils.newFloatBuffer(16);
gl.glGetFloatv(GL.GL_PROJECTION_MATRIX, prBuffer);
double prArray[] = new double[4*4];
for (int x = 0; x < 4; x++)
for (int y = 0; y < 4; y++)
prArray[x*4+y] = prBuffer.get();
// Viewport matrix
IntBuffer vpBuffer = BufferUtils.newIntBuffer(16);
gl.glGetIntegerv(GL.GL_VIEWPORT, vpBuffer);
int[] vpArray = new int[vpBuffer.capacity()];
for (int i = 0; i < vpArray.length; i++) {
vpArray[i] = vpBuffer.get();
}
public Vector3f getWorldCoordinates(Vector2f screenPosition, float zPos, Vector3f store) {
if (store == null) store = new Vector3f();
// Modelview matrix
FloatBuffer mvBuffer = BufferUtils.newFloatBuffer(16);
gl.glGetFloatv(GL.GL_MODELVIEW_MATRIX, mvBuffer);
double mvArray[] = new double[4*4];
for (int x = 0; x < 4; x++)
for (int y = 0; y < 4; y++)
mvArray[x*4+y] = mvBuffer.get();
// Projection_matrix
FloatBuffer prBuffer = BufferUtils.newFloatBuffer(16);
gl.glGetFloatv(GL.GL_PROJECTION_MATRIX, prBuffer);
double prArray[] = new double[4*4];
for (int x = 0; x < 4; x++)
for (int y = 0; y < 4; y++)
prArray[x*4+y] = prBuffer.get();
// 3d coordinates
double[] result = new double[3];
int[] vpArray = new int[vpBuffer.capacity()];
for (int i = 0; i < vpArray.length; i++) {
vpArray[i] = vpBuffer.get();
}
glu.gluUnProject((double)screenPosition.x,
(double)screenPosition.y,
(double)zPos,
mvArray,
prArray,
vpArray,
result);
Alright got past that problem only 2 errors left and jogl renderer,displaysystem,states,front,and camera will all be jme .9 compatable only thing left out is input which I'd again be greatfull if somebody would do that. Right now it only supports AWT just because of ease to convert. Thanks Badmi for the wealth of ideas