JOGL Support (JOGL2 that is)

Development
121
@gouessej said:
Thanks. I still have a lot of features to implement and JMonkeyEngine 3.0 will end up with 2 renderers based on JOGL 2.0 available as "external modules" or as part of the engine. I hope I haven't wasted my time.

Why two renderers? We only need one with a working fixedfunc pipeline? Or do you mean a GLES renderer? :D
122
@normen said:
Why two renderers? We only need one with a working fixedfunc pipeline? Or do you mean a GLES renderer? :D

I ported the shader-based renderer and the renderer based on the fixed pipeline, you can see that they are in 2 separate classes like for those relying on the competitor of JOGL. Did I do something wrong?
123

Ah, I thought theres only one class by now that also does the fixedfunc pipeline for the lwjgl renderer, my bad.

124

Itā€™s almost 2 oā€™clock. The bugs are fixed, both renderers work just fine. Good night.

7 Likes
125

jocl/jogl interop, nice. I suppose thatā€™s out of the question for jME thoā€¦

126
@androlo said:
jocl/jogl interop, nice. I suppose that's out of the question for jME tho...

Not really, if you read the thread this effort is being made because we intend to move away from lwjgl.
127

@normen I would like to check whether NEWT works fine under Mac OS X 10.6.8 before using it in JMonkeyEngine 3. Please can you try this demo?

128
@gouessej said:
@normen I would like to check whether NEWT works fine under Mac OS X 10.6.8 before using it in JMonkeyEngine 3. Please can you try this demo?

Do you mean 10.6.8? I have one computer in my studio with that on it still. Or do you mean 10.8.2?
129
@normen said:
Do you mean 10.6.8? I have one computer in my studio with that on it still. Or do you mean 10.8.2?

Sorry, I meant 10.8.2, you're right. There's only one soldier, you should succeed in kicking his ass easily :)
130

Hm I seem to have issues with starting it in the first placeā€¦ I got the new Java7 plugin for jnlp files and it just shows me the java7 splash screen, then does nothing. No output to console, idk where I could look for other logsā€¦ Iā€™ll investigate further.



At any instance Iā€™d like to see the jme renderer using newt, its much much cleaner and slicker than anything else and pretty much looks exactly like what we would want to have for our engine. The only question is how we could get a canvas to work with this? I guess it might be a bit harder? If it wouldnā€™t work at all, maybe we can move to a completely in-memory rendered solution (backbuffer painted to awt) completely for this as most ā€œhigh profileā€ applications probably will use just a native window. Question that remains then is appletsā€¦

131

ocl/ogl interop requires that the cl context is created first afaik, regardless of wrapper. I suppose jme dont want to run on a cl context.

132
@normen said:
Hm I seem to have issues with starting it in the first place.. I got the new Java7 plugin for jnlp files and it just shows me the java7 splash screen, then does nothing. No output to console, idk where I could look for other logs.. I'll investigate further.

It would be nice to understand what's wrong.

@normen said:
At any instance I'd like to see the jme renderer using newt, its much much cleaner and slicker than anything else and pretty much looks exactly like what we would want to have for our engine. The only question is how we could get a canvas to work with this? I guess it might be a bit harder? If it wouldn't work at all, maybe we can move to a completely in-memory rendered solution (backbuffer painted to awt) completely for this as most "high profile" applications probably will use just a native window. Question that remains then is applets..

I already did something similar for another engine and now JOGL 2.0 has a kind of high level API for FBO and PBuffer. I remind you that it is easy to create a NEWT window and to attach it to a bridge.

@androlo said:
ocl/ogl interop requires that the cl context is created first afaik, regardless of wrapper. I suppose jme dont want to run on a cl context.

We can use a flag to enable this interoperability and create the OpenCL context first when it is set to true.
1 Like
133
@androlo said:
ocl/ogl interop requires that the cl context is created first afaik, regardless of wrapper. I suppose jme dont want to run on a cl context.

What are you talking about? Whats the deal with OpenCL suddenly? :) If we start adding OpenCL we will look into how the context is accessible from both sides or have two contexts and a proper way to reference data on both sides.

@gouessej said:
I already did something similar for another engine and now JOGL 2.0 has a kind of high level API for FBO and PBuffer. I remind you that it is easy to create a NEWT window and to attach it to a bridge.

Ok cool, we just want it as slim as possible. Swing/AWT is a necessity esp. for the SDK but ideally jme games don't depend on it really. If that would mean that awt-compatible rendering has to happen in a separate system that'd be okay. If newt plays nice without bloating "its" classes for creating windows etc., cool :)

I hope I'll have more time to dig into this stuff from my side more, for now I hope @Momoko_Fan also reserves some time for this :) Thanks for all the work you put in already!
134
@normen said:
Ok cool, we just want it as slim as possible. Swing/AWT is a necessity esp. for the SDK but ideally jme games don't depend on it really. If that would mean that awt-compatible rendering has to happen in a separate system that'd be okay. If newt plays nice without bloating "its" classes for creating windows etc., cool :)

I hope I'll have more time to dig into this stuff from my side more, for now I hope @Momoko_Fan also reserves some time for this :) Thanks for all the work you put in already!

Look at this if you want to understand what I mean, it is simple. Is off-screen rendering mandatory? Actually, I don't see the source code responsible for the interoperability between AWT and the competitor of JOGL. I still have a lot of things to do. You're welcome :)
135
@gouessej said:
Look at this if you want to understand what I mean, it is simple. Is off-screen rendering mandatory? Actually, I don't see the source code responsible for the interoperability between AWT and the competitor of JOGL. I still have a lot of things to do. You're welcome :)

Off screen rendering should be in, yes. There might be opengl and maybe opencl operations done server-side or example. Or simply for rendering elsewhere in general (e.g. Syphon on OSX).

Edit: The newt / AWT bridge seems easy enough :) Just supplying that when a canvas context is created should be fine, cool.
136

I fiddled around with lwjglā€™s opencl wrapper a while back. I think what I found out was that you couldnā€™t use it with jME because it required the cl context to be created first, then the ogl system somehow adapted to it. I assumed it ment the cl context had to be the primary ā€˜handlerā€™ of all objects, due to some hardware crap (not the other way around). Perhaps I was wrong. I didnā€™t follow up because I figured the jME core would not be changed for something like that, but decided to lurk until an opportunity presented itself. I know its not a priority compared to all the other stuff, but it would be great for biomonkey.

137
@androlo said:
I fiddled around with lwjgl's opencl wrapper a while back. I think what I found out was that you couldn't use it with jME because it required the cl context to be created first, then the ogl system somehow adapted to it. I assumed it ment the cl context had to be the primary 'handler' of all objects, due to some hardware crap (not the other way around). Perhaps I was wrong. I didn't follow up because I figured the jME core would not be changed for something like that, but decided to lurk until an opportunity presented itself. I know its not a priority compared to all the other stuff, but it would be great for biomonkey.

Yeah but really its just an implementation detail in how the renderer is initialized in the end :) Don't think we'll get to this soon though, especially not with context sharing / purposeful data transfer.
138

We donā€™t actually need off screen rendering, we just need to have an OpenGL context without anything visible at all. Both canvas and AWT panels need this context so that they can do their rendering ā€¦



However with JOGL, we can actually replace both canvas and AWT panels with the JOGL equivalents, the GLCanvas and GLJPanel objects.

139
@Momoko_Fan said:
We don't actually need off screen rendering, we just need to have an OpenGL context without anything visible at all. Both canvas and AWT panels need this context so that they can do their rendering ...

However with JOGL, we can actually replace both canvas and AWT panels with the JOGL equivalents, the GLCanvas and GLJPanel objects.

I can provide some support of off-screen and headless rendering. AwtPanel extends java.awt.Canvas, it could rather use GLCanvas. I'm not sure you need GLJPanel except in some particular cases and it uses FBOs and PBuffers under the hood, avoiding to use it would allow to get better performance on lots of machines, especially laptops with Intel chips, I remind you that WebGL is often slow and less reliable because its implementations rely on FBOs which is a bad idea in my humble opinion.

@normen Please don't forget to send me the logs. I really want NEWT to work fine on Mac OS X 10.8.2. If there is a bug in Oracle JDK 1.7, we have to report it as soon as possible.
140

@Momoko_Fan: for the mentioned examples Iā€™d like to have offscreen rendering still.

@gouessej: I canā€™t get TƜR to give me output, even starting javaws from command line doesnā€™t yield anyā€¦ It just doesnā€™t seem to download, idk. But as said I am having issues with java anyway here :confused: