JOGL Support (JOGL2 that is)

nehon · February 17, 2012, 5:10pm

@gouessej said:
Keep in mind that in some cases a developper who wants to add new features for his own project may have to imrpove the renderer itself.

That's something we absolutely want to avoid..... JME's users shouldn't have to do things on the renderer level.

@gouessej said:
I wrote the main part of the port of Java3D in 4 hours during 2 days. That's not that hard. It would only take a few days for JMonkeyEngine if I used directly NEWT without AWT.

That's not the issue, the issue in maintenance. Each time someone from the team modifies something in the renderer we would have to do it twice.
That's what happened in the beginning we had 2 renderers, the LWJGL one that was maintained and the JOGL one that was updated...sometimes...later...
In the end what users recall is that the LWJGL renderer works but not the JOGL one...that's not really good for JOGL in the end.

gouessej · February 17, 2012, 9:33pm

@nehon said:
That's something we absolutely want to avoid..... JME's users shouldn't have to do things on the renderer level.

I understand your position but it is sometimes impossible to avoid except if you prefer some users to switch to a more flexible and permissive technology.

@nehon said:
That's not the issue, the issue in maintenance. Each time someone from the team modifies something in the renderer we would have to do it twice.
That's what happened in the beginning we had 2 renderers, the LWJGL one that was maintained and the JOGL one that was updated...sometimes...later...
In the end what users recall is that the LWJGL renderer works but not the JOGL one...that's not really good for JOGL in the end.

That's why the official team won't have to do this. I have just suggested to Sven that we write our own renderer and we will maintain it with our own means. It will solve the problem. Officially, JMonkeyEngine 3 will only support LWJGL but another renderer will be able on JogAmp.org, it won't be your responsibility. Please just avoid to put very low level LWJGL calls everywhere and that won't cause any problem to us.

Is this solution better in your humble opinion?

normen · February 17, 2012, 9:49pm

@gouessej said:
Is this solution better in your humble opinion?

:facepalm: thats what we say all the time.

Momoko_Fan · February 18, 2012, 3:11am

@gouessej said:
That's why the official team won't have to do this. I have just suggested to Sven that we write our own renderer and we will maintain it with our own means. It will solve the problem. Officially, JMonkeyEngine 3 will only support LWJGL but another renderer will be able on JogAmp.org, it won't be your responsibility. Please just avoid to put very low level LWJGL calls everywhere and that won't cause any problem to us.

We do not have any LWJGL calls in core code as that would break Android compatibility. You should be able to write your own context, renderer and input implementation just like you did it a year ago.

We do have some specifics when it comes to native extraction however, at the moment it is hardcoded for certain contexts. We use the "org.lwjgl.librarypath" and "net.java.games.input.librarypath" system properties to specify where LWJGL and JInput can locate the native libraries. This is needed on Linux where the working directory isn't in the PATH by default so a native extraction method relying on regular Java behavior won't work. I assume JOGL2 provides an equivalent method that you can use.

nehon · February 18, 2012, 7:36am

@gouessej said:
That's why the official team won't have to do this. I have just suggested to Sven that we write our own renderer and we will maintain it with our own means. It will solve the problem. Officially, JMonkeyEngine 3 will only support LWJGL but another renderer will be able on JogAmp.org, it won't be your responsibility. Please just avoid to put very low level LWJGL calls everywhere and that won't cause any problem to us.

Is this solution better in your humble opinion?

We don't have LWJGL calls everywhere, that's the point of the renderer.
Users on the other hand might have, despite the fact we strongly discourage it. But I guess it's there own issue.
If you have your own plugable renderer, and that you are willing to spend time, maintaining it, that's fine for me.

gouessej · February 18, 2012, 9:29am

@normen said:
:facepalm: thats what we say all the time.

I admit you're right but if the JOGL renderer was in your trunk, it would be more visible. Anyway, if Sven agrees with me, we will maintain and host our own renderer.

@Momoko_Fan said:
We do not have any LWJGL calls in core code as that would break Android compatibility. You should be able to write your own context, renderer and input implementation just like you did it a year ago.

That's what I expected.

@Momoko_Fan said:
We do have some specifics when it comes to native extraction however, at the moment it is hardcoded for certain contexts. We use the "org.lwjgl.librarypath" and "net.java.games.input.librarypath" system properties to specify where LWJGL and JInput can locate the native libraries. This is needed on Linux where the working directory isn't in the PATH by default so a native extraction method relying on regular Java behavior won't work. I assume JOGL2 provides an equivalent method that you can use.

Thanks for your precise explanation. I might use an alternative implementation of JInput including some compatibility with NEWT (our native windowing system). JOGL 2.0 has an extremely robust automatic extractor of native libraries, there is no need to set the Java library path or anything like that (LD_LIBRARY_PATH on GNU Linux), it extracts the proper native libraries from JARs and loads them dynamically on any supported platform.

@nehon said:
We don't have LWJGL calls everywhere, that's the point of the renderer.
Users on the other hand might have, despite the fact we strongly discourage it. But I guess it's there own issue.
If you have your own plugable renderer, and that you are willing to spend time, maintaining it, that's fine for me.

Actually, I would like to use continuous integration with Jenkins so that when something is changed in the LWJGL renderer or when the JOGL renderer cannot be compiled anymore, I'm alerted and I can fix it quickly. I would like to do it for some other engines too. My aim is not to spend a lot of time on it but we are ready to frequently spend a bit of time to keep it working and stable. Best regards.

erlend_sh · February 18, 2012, 10:04pm

Glad we got that out of our systems… Right, so @sgothel where do you see this going from here?

sgothel · February 28, 2012, 10:23am

Hi All, sorry for being absent … maybe it was helping myself to get a clear view

First of all, I agree w/ JME Team, that nobody can dictate anything to you guys.

As far as I understand there might be a Window of opportunity for JOGL/JME in case

you like to switch to JOGL. However, I don’t want to cause bad blood w/ LWJGL

or even compete w/ their project at all. Actually it’s good spirit to have some redundancies

and LWJGL are welcome to look at our code base and cherry pick, as we are.

It’s really not a matter of life or death

Since lots of things are up on my desk anyways in supporting JogAmp,

I guess it’s best for myself to concentrate on supporting the user base well

and enhancing our stuff. Of course, myself, Julien, Wade, Rami, Dominik

and many other will help supporting JOGL etc in our forum.

So … let’s say, you would be very welcome as a high-priority ‘customer’

including quality support.

In case Julien really wants to go through all the hurdles and maintain

an alternative JME backend using JOGL, I will do my best to support this work.

I am very much aware of the difficulties of such endeavor and you are right saying

it’s not the actual porting work, but the reliable maintenance which breaks ones neck if it lags

So all good and keep up w/ your great work.

Let’s just say ‘laters’

Cheers, Sven

erlend_sh · February 28, 2012, 1:01pm

It’s good to know you’re out there Sven Thanks for a good, open conversation.

I wish you and your fellow developers the best of luck. And hey, we sure wouldn’t mind being part of your demo at SIGGRAPH 2012, even if just as a proof of concept.

gouessej · February 28, 2012, 1:09pm

@erlend_sh said:
It's good to know you're out there Sven ;) Thanks for a good, open conversation.

I wish you and your fellow developers the best of luck. And hey, we sure wouldn't mind being part of your demo at SIGGRAPH 2012, even if just as a proof of concept.

I have to finish some tasks on Xith3D. After that, I will port the shader-based renderer of JMonkeyEngine 3.

normen · October 22, 2012, 3:53am

@gouessej said:
I have to finish some tasks on Xith3D. After that, I will port the shader-based renderer of JMonkeyEngine 3.

Did this happen? We are more seriously considering JOGL as the jME GL wrapper.

gouessej · October 22, 2012, 8:24am

@normen said:
Did this happen? We are more seriously considering JOGL as the jME GL wrapper.

I can do that this week. I will probably spend 3 days on this task. I might need some help only for a very few things as some parts might be tightly linked to the other Java binding for the OpenGL API you use.

Edit.: I will have to modify a bit Nifty GUI too but it should not take a long time.

Edit.2: I'll port the audio renderer to JOAL 1.1.3 too, is it ok for you?

Edit.3: JInput for JogAmp is not yet ready.

Edit.4: a few methods (setNativeCursor) won't be ported until they are supported by NEWT (JOGL 2.0 native windowing toolkit).

Edit.5: I'll port the GL1 renderer too.

Edit.6: The "trickiest" part to port is the input handling because NEWT is still event based.

Edit.7: I plan to put the source code into JogAmp official repositories, let me know whether you agree with my decision.

kwando · October 22, 2012, 9:00am

@normen said:
Did this happen? We are more seriously considering JOGL as the jME GL wrapper.

Just out of curiosity, why is JOGL better for jME?

mifth · October 22, 2012, 9:03am

What if @gouessej will be a maintainer of JOGL for JME3?

But it seems coredevs don’t want 2 renderers.

I think if the core devs decide to move to JOGL they will do it by ourselves.

gouessej · October 22, 2012, 9:07am

@kwando said:
Just out of curiosity, why is JOGL better for jME?

I don't want to open a new debate about this subject, I just do my "job" as the guy responsible for engine support at the JogAmp Foundation.

@mifth said:
What if @gouessej will be a maintainer of JOGL for JME3?
But it seems coredevs don't want 2 renderers.

I think if the core devs decide to move to JOGL they will do it by ourselves.

I only plan to port JMonkeyEngine 3.0 to JOGL 2.0 (RC11). It does not force you to use it.

kwando · October 22, 2012, 9:13am

@gouessej My question was not directly towards you My purpose was not to start a new lengthy debate about which OGL wrapper to use.

I’m only curious why a migration to JOGL is under consideration, or more precisely whats wrong with the current and working LWJGL renderer? (except the recent troubles on macs).

gouessej · October 22, 2012, 9:40am

@kwando said:
@gouessej My question was not directly towards you :) My purpose was not to start a new lengthy debate about which OGL wrapper to use.

But such a debate may start as soon as we speak about which Java binding for the OpenGL(-ES) API to use.

@kwando said:
I'm only curious why a migration to JOGL is under consideration, or more precisely whats wrong with the current and working LWJGL renderer? (except the recent troubles on macs).

I only agree with porting JMonkeyEngine 3.0 to JOGL 2.0; Normen and the core developers are not forced to host the source code on their own repositories and this port will be available as an extension if it is not in the core. I don't want my efforts to be "wasted". JMonkeyEngine 3.0 will have some JOGL support before its first stable release. It's not up to me to decide whether a migration to JOGL will occur or not. I can only say that JogAmp APIs are very actively maintained, we have a true bug tracker, JOGL 2.0 supports OpenGL-ES too, it works even on a Raspberry Pi. I still plan to put the source code onto JogAmp official repositories. Using free softwares is about freedom, you're free to stick with the competitor of JOGL, I'm free to provide an additional support of JOGL for JMonkeyEngine 3.0.

normen · October 22, 2012, 10:58am

@gouessej said:
I can do that this week. I will probably spend 3 days on this task. I might need some help only for a very few things as some parts might be tightly linked to the other Java binding for the OpenGL API you use.

Edit.: I will have to modify a bit Nifty GUI too but it should not take a long time.

Edit.2: I'll port the audio renderer to JOAL 1.1.3 too, is it ok for you?

Edit.3: JInput for JogAmp is not yet ready.

Edit.4: a few methods (setNativeCursor) won't be ported until they are supported by NEWT (JOGL 2.0 native windowing toolkit).

Edit.5: I'll port the GL1 renderer too.

Edit.6: The "trickiest" part to port is the input handling because NEWT is still event based.

Edit.7: I plan to put the source code into JogAmp official repositories, let me know whether you agree with my decision.

Oh cool, thanks :)

1) Okay, yes nifty integration would be important
2) I guess do, what kind of API does it use "under the hood"?
3) So how does input happen?
4) Yeah, these have issues in lwjgl/latest osx too
5) Yes, support for fixed func bindings would be good too :)
6) So how does input happen?
7) Yes, that would be fine. However if we actually move to JOGL we'd probably like to maintain it ourselves.

@kwando: For various reasons ;p Gouessej nicely put them together on the first page.

gouessej · October 22, 2012, 11:16am

@normen said:
Oh cool, thanks :)

I will start this port this night or tomorrow morning. I will take some days off in order to work on it carefully.

@normen said:
1) Okay, yes nifty integration would be important

I just have to update the current renderer based on JOGL 2.0 for Nifty GUI and to check whether I can use it as is with JMonkeyEngine 3.0.

@normen said:
2) I guess do, what kind of API does it use "under the hood"?

OpenAL (and OpenALSoft as a fallback).

@normen said:
3) So how does input happen?

I can use the existing version of JInput For JogAmp but it is not fully integrated with JOGL. I will use NEWT for keyboard and mouse input.

@normen said:
4) Yeah, these have issues in lwjgl/latest osx too

Don't worry, they are not numerous, it mainly concerns cursors and icons.

@normen said:
5) Yes, support for fixed func bindings would be good too :)

Ok.

@normen said:
6) So how does input happen?

I will use NEWT event-based system as a polling system as we (Renanse, some other people and me) did for some other engines.

@normen said:
7) Yes, that would be fine. However if we actually move to JOGL we'd probably like to maintain it ourselves.

That's ok for me. I just want my work not to be "wasted" whatever the core developers of JMonkeyEngine 3.0 decide. I try to keep each engine actively supported with the latest versions of JOGL 2.0, JOAL and JOCL.

@normen said:
@kwando: For various reasons ;p Gouessej nicely put them together on the first page.

I still have to check whether Maven support works flawlessly.

I would like to commit the source code as soon as possible so that some people can give it a try under Windows and Mac as I'm exclusively under GNU Linux (Mageia Linux 2 & Debian Squeeze).

normen · October 22, 2012, 12:24pm

Sounds good, thanks very much.