JOGL Support (JOGL2 that is)

Development
281

Hi

I’ll implement com.jme3.input.jogl.NewtMouseInput.setNativeCursor(JmeCursor) by using the image data (RGBA?) of com.jme3.cursors.plugins.JmeCursor. Another method has to be added into NEWT to pass directly a byte buffer when creating a pointer icon used as a mouse cursor.

2 Likes
282
@gouessej said: Hi

I’ll implement com.jme3.input.jogl.NewtMouseInput.setNativeCursor(JmeCursor) by using the image data (RGBA?) of com.jme3.cursors.plugins.JmeCursor. Another method has to be added into NEWT to pass directly a byte buffer when creating a pointer icon used as a mouse cursor.

Cool, but don’t hack up your code too much for us :wink: The JmeCursor is kind of a feature creep and only really supported on desktop. I am in the process of changing the jme build process to gradle btw, we should then be able to use the jogl maven artifacts so you don’t have to update the jar binaries anymore.

3 Likes
283
@normen said: Cool, but don't hack up your code too much for us ;) The JmeCursor is kind of a feature creep and only really supported on desktop.
I have to implement a similar feature in another engine too, the new public NEWT method might consist in exposing a previously private method into a safe public one and it will be used in both engines. That way I'll be able to provide an implementation closer to the one using JogAmp main competitor.
@normen said: I am in the process of changing the jme build process to gradle btw, we should then be able to use the jogl maven artifacts so you don't have to update the jar binaries anymore.
Thank you very much :) My script was useful in the meantime.
284

Hi

I’ve just provided a first implementation highly inspired of the one I made yesterday for another engine but in which pixel format is the content of a JmeCursor? This class just wraps a class of JogAmp’s main competitor, it is probably in RGBA but I just want to be sure it’s the case. Please can someone confirm this information?

285

Hi

I’ll switch to JOGL 2.1.4 as soon as possible. I plan to start working on NEWT Input API in some weeks first in JOGL itself and then in several engines including JMonkeyEngine 3 of course.

3 Likes
286
@gouessej said: Hi

I’ll switch to JOGL 2.1.4 as soon as possible. I plan to start working on NEWT Input API in some weeks first in JOGL itself and then in several engines including JMonkeyEngine 3 of course.


Awesome! can’t wait ^^

287

Hi

Normen switched to JOGL 2.1.4 (thanks) but JOGL 2.1.5-01 is already available. Best regards.

4 Likes
288

Hi

I’ll switch to JOGL 2.2 in some weeks or maybe a month. It supports the HiDPI mode under Mac OS X thanks to Sven :slight_smile: The canvas based on NEWT will use it by default when it is available.

1 Like
289
@gouessej said: Hi

I’ll switch to JOGL 2.2 in some weeks or maybe a month. It supports the HiDPI mode under Mac OS X thanks to Sven :slight_smile: The canvas based on NEWT will use it by default when it is available.


I figured I’ll let you know: There’s currently a plan to switch to a different rendering method in jME3. Instead of the abstraction occuring in the Renderer interface, we plan to have a GL interface and then Renderer becomes a concrete class. In that case we’ll have implementations like LwjglGL, JoglGL, AndroidGL, IosGL, etc. This will also avoid the headache of having to apply every change in one renderer class to every other renderer class.
You can see some preliminary work on this in the jme3-gl-autogen project that was added recently.

290

Oh cool, this will help, making a gl abstract renderer makes no sense for jme as due to glsl we are bound to opengl anyway.

291

Hi

The stable version of JOGL 2.2.0 will be available soon, it supports virtual reality (especially Oculus Rift) but I don’t know how I could use it in JMonkeyEngine 3 yet.

Edit.: Someone else has already worked on adding Oculus Rift support into JMonkeyEngine for more than one year. I assume that my help won’t be necessary.
Edit.2: I notice that some contributors forgot to port their changes to this backend…

@Momoko_Fan If your suggestion is designed with another API in mind and not suitable to JOGL, we’ll have a problem. If it helps to drastically reduce the efforts to support several backends, it will be worth the efforts. However, it’s impossible to make something similar for the source code very close to the windowing systems.

292

Hi

JOGL 2.2.0 is available, I’ll update the source code very soon, I’ll port a few missing things. I haven’t committed anything since the switch to Github, I hope it will work flawlessly.

2 Likes
293

Hi

@normen Should I make a pull request? I’ve just tried to make a first commit:
remote: Permission to jMonkeyEngine/jmonkeyengine.git denied to gouessej

294

I’ve just committed my changes, I thank Nehon for the commit rights:

1 Like
295

@gouessej: Thanks, you can cut out the snarky comments though, you offered to do this to push your JOGL agenda. The current official renderer is still the LWJGL one, Momoko explained that the renderer interface will be unified, so merging the changes will be our problem anyway.

296

@normen I think that there were some misunderstandings. I assumed that the other JMonkeyEngine contributors could at least port their changes from the current official renderer to the JOGL renderer one by one instead of making their changes only on the former and leaving the latter unchanged, that was what I understood when someone claimed that the JMonkeyEngine contributors would host and maintain the JOGL renderer by themselves and this is probably not what I should have understood. I didn’t imagine that the JMonkeyEngine contributors would believe that there was no longer any need to port their changes to the JOGL renderer as the unified renderer interface (jme3-gl-autogen?) isn’t ready yet. I’m sorry.

Edit.: Let me know whether there is anything else I should edit. I don’t want to cause any trouble.

297
@gouessej said: @normen I think that there were some misunderstandings. I assumed that the other JMonkeyEngine contributors could at least port their changes from the current official renderer to the JOGL renderer one by one instead of making their changes only on the former and leaving the latter unchanged, that was what I understood when someone claimed that the JMonkeyEngine contributors would host and maintain the JOGL renderer by themselves and this is probably not what I should have understood. I didn't imagine that the JMonkeyEngine contributors would believe that there was no longer any need to port their changes to the JOGL renderer as the unified renderer interface (jme3-gl-autogen?) isn't ready yet. I'm sorry.

Edit.: Let me know whether there is anything else I should edit. I don’t want to cause any trouble.

Well I just thought I had to mention it as I saw these comments in various places now, github comments, the forum, commit messages etc. I repeat, the JOGL renderer is NOT something we advise users to run jME with, even if you might do so. Its a WIP and its good you implemented it this far already so we can test various things. The final desktop renderer for jME 3.1 won’t be the current JOGL renderer and not the current LWJGL renderer either, it will be a new renderer that will most probably use JOGL as the OpenGL wrapper on desktop, simply because LWJGL has too many issues. We will not support multiple desktop renderers now or any time in the future! And we still regard LWJGL and JOGL as simple wrappers for OpenGL with a bit of window management on top, we are not interested in any extended features. So that explains everything else I guess.

298

The JOGL renderer is used with the Raspberry Pi too, it uses OpenGL-ES under GNU Linux on ARM. Do you consider it is an extended feature?

Does it mean that JMonkeyEngine will use its own windowing toolkit? This information is important for me, I’d like to know whether I’ll have to use the NEWT Input API when it’s ready and how JMonkeyEngine will become able to manage several windows at the same time.

299
@gouessej said: The JOGL renderer is used with the Raspberry Pi too, it uses OpenGL-ES under GNU Linux on ARM. Do you consider it is an extended feature?

Does it mean that JMonkeyEngine will use its own windowing toolkit? This information is important for me, I’d like to know whether I’ll have to use the NEWT Input API when it’s ready and how JMonkeyEngine will become able to manage several windows at the same time.

jME will abstract the windowing stuffs over whatever backend is used. Some of this is a bit convoluted at the moment, we intend to change that with the new unified renderer, then we will just need some way to tell the renderer to open a window, pass a link to an AWT surface etc. So theres nothing in the way of using NEWT in the background but the whole NEWT API won’t be made accessible from the jME side. If you want to change the current renderer so that it uses the APIs you deem most appropriate for jME we can use that code to adapt the new renderer.

Edit: And for the RasPI support etc… I guess the “plugability” of JOGL would be an extended feature, yes. From what I get we’d simply take a premade RasPI JOGL version and plug in our OpenGL(ES) renderer. We could just as well use a native interface though, if configuring JOGL takes more time than adapting the render code to do something you can regard that as “extended” :wink:

300

Abstracting windowing stuffs is easy if and only if you don’t allow the end users to modify the resolution, if you allow only the use of the default virtual monitor. @Momoko_Fan seems to talk above several renderers for the desktop whereas you talk about a single renderer :s I understand that you want the jME users to be “clients” of the jME API by wrapping NEWT or anything else.