JOGL Support (JOGL2 that is)

[sgothel]

Hi All,



Intro:

---

I am the lead developer of JOGL/JogAmp.
We are currently getting close to the 2.0 release and RC6 will be pushed out tomorrow.

Support is available w/ autobuilds and test on all usual suspects
- Linux, Windows, Solaris and OSX (10.5 - 10.7) on x86 and x86_64
- Linux on ARMv7[1]
- Android on ARMv7[1]

Besides AWT, we support our own windowing toolkit NEWT. An SWT canvas is available as well.
NEWT would be the versatile TK, available on all platforms (incl. mobile).

[1] autobuild/test pending

---

Request / JOGL Scenegraph / Game-Engine support:

---

I know that Julien Gouesse currently has an Ardor3D port underway,
not merged w/ upstream. He also did some work regarding jme2, not merged either AFAIK.
Last days he also ported Java3D to use JOGL as it's sole renderer.

However .. I was looking up the current situation in the open source game engine area
and sure I couldn't miss you guys. The buzz words: Shader Based, Mobile, Complete Rewrite
were enough to catch my eye :)

How can I contribute a new JOGL renderer for your latest jme3 in a way
that it gets merged into your codebased - supported by myself and others ?
I would love to show your jme3 running on top of JOGL across devices (incl. android)
on our BOF @ SIGGRAPH2012.
What I don't want (of course) is to create a dead branch and future dead code
nobody likes to merge upstream :)

Simple question: Would you welcome a new JOGL2 renderer into your codebase ?

Please advise.

Cheers, Sven

[erlend_sh]

Thanks for getting in touch Sven.



Being the lead developer of JOGL, you’ve certainly got our attention. Of course you know like we do, that this is no small undertaking, with considerable implications. We tried supporting two renderers (LWJGL & JOGL 1) in the past, and that turned out to not be feasible, especially because neither renderer was actively supported by its respective developers in a jME context.

Simple question: Would you welcome a new JOGL2 renderer into your codebase ?

If you complete and maintain a new JOGL2 renderer for jME3, it won't go into the trunk first thing. What we could make sure to do initially would be making developers well aware of the JOGL2 option (blog post, clear links, wiki page). I'm expecting the jME developers to chip in on how exactly this option would work in terms of usability.

In order to make it into trunk, i.e. bundled by default with the jME3 SDK, you'd have to outperform LWJGL somehow. How you might do that is up to you. I'd say technology and communication (mainly jME3-JOGL2 support on our forums) are the biggest factors in this decision.

Once again, it's great that we're having this discussion. If I come off sounding negative that is not my intention; I'm merely being cautious. I've been keeping up with the JogAmp blog(s) and you guys are making great progress. I'm looking forward to exploring this further.

[sgothel]

Thank you Erlend. No, it doesn’t sound negative at all, more realistic.

I don’t think in the direction of ‘competition’ and ‘outperform’, but in terms of variety and availability.



A primary question would here is: In case the higher level rendering modules are using LWJGL directly,

hence have no API abstraction layer, would jme allow such a layer?

If the answer is ‘no’ - I guess I don’t even need to start. But of course, I assume the answer is yes



To be practical, to start things I would need:

• know the proper branch of jme to fork / branch I assume it’s trunk ?
  
• a branch in your repository, so awareness and visibility is at least given (you guys still use SVN?!)
  
• having a JOGL subforum, maybe after I declared a port is working with JOGL, JOAL, JOCL … etc
  
• a contact person I can email and chat (maybe via the new JOGL forum?)
  
  
  
  Having this, I would start doing the evaluation and work, discussing it in the <sub>forum.
  
  
  
  ~Sven</sub>

[sbook]

Hi Sven,

@sgothel said:A primary question would here is: In case the higher level rendering modules are using LWJGL directly,
hence have no API abstraction layer, would jme allow such a layer?
If the answer is 'no' - I guess I don't even need to start. But of course, I assume the answer is yes :)

Lucky for you, the answer is yes!

@sgothel said:- know the proper branch of jme to fork / branch :) I assume it's trunk ?

trunk/engine is what you'd want. That's where the actual engine itself is. The SDK folder is for something else, the identity of which you can probably guess ;)

If you check the project out into NetBeans the structure of the sources will be quite evident and you can have a look at the LWJGL render implementation to get an idea of how the abstraction works.. As far as input goes, we already have an AWT input system for canvas use.

@sgothel said:- a branch in your repository, so awareness and visibility is at least given (you guys still use SVN?!)

We had some discussion about this, as there is the core repository (jmonkeyengine.googlecode.com) and the user contributions repository (jmonkeyplatform-contributions.googlecode.com). It would make sense for this to be in the core once its ready to go. That said, we do have people (some exquisitely brave people) working with nightly builds of the engine. I'll defer to others on the core team about when the code should be integrated.

Yes, we're still on SVN.

@sgothel said:- having a JOGL subforum, maybe after I declared a port is working with JOGL, JOAL, JOCL .. etc

We have a development subforum which is pretty low traffic compared to the troubleshooting parts of the forum...

@sgothel said:- a contact person I can email and chat (maybe via the new JOGL forum?)

Yes of course.. Forum is probably the best mode of contact due to its all-inclusive nature but there is also 'offline' communications, via Jabber mostly.

I hope this has helped some!

[Empire_Phoenix]

Hey one question,



what is the main difference between jogl and lwjgl, as far as I understand the basic way both work is that they are more or less just a small wrapper for the opengl c functions.

But I guess there must be some conceptial or similar differences and wonder what they are.





( Btw a way I think would be superior to lwjgl would be the ability to have 2 methods for creating and releasing bytebuffers on the native side, without the use of some jvm/refelction hacks as jme currently has to do it, (manuall releasing is needed due to the poor way directmemory is released by the garbagecollector under certain cirumstances when chruning through a lot of directmemory))

[tralala]

@EmpirePhoenix : use this to solve your issues :



[java]

public static FloatBuffer createFloatBuffer(int size)

{

int crashes = 0;

FloatBuffer fb = null;

while (fb == null)

{

try

{

//System.out.println(size);

fb = BufferUtils.createFloatBuffer(size);

}

catch (OutOfMemoryError oom)

{

System.out.println("Warning: out of memory. Garbage collecting. Crash : "+(crashes+1));

System.gc();

if (crashes > 0) try

{

Thread.sleep(100);

}

catch (InterruptedException ex)

{

}

}

}



return fb;

}



public static ByteBuffer createByteBuffer(int size)

{

int crashes = 0;

ByteBuffer fb = null;

while (fb == null)

{

try

{

fb = BufferUtils.createByteBuffer(size);

}

catch (OutOfMemoryError oom)

{

System.out.println("Warning: out of memory. Garbage collecting. Crash : "+(crashes+1));

System.gc();

if (crashes > 0) try

{

Thread.sleep(100);

}

catch (InterruptedException ex)

{

}

}

}



return fb;

}

[/java]

[Empire_Phoenix]

Yes I know this is a workaround, but no real fix, I currently use the BufferUtils.destrysomwaht methd, that internally calls with reflection magic some hidden Cleaner stuff, neither are a real fine solution, having this kind of functionality in the fundament of the engine (lwjgl or jogl) would be kind of nice.



(Btw in tests I had to use up to 5seconds delay, i really churn trough much memory for the dynamic terrain vegetation stuff i’m doing)

[sgothel]

@sbook: Thanks, yes - helped a lot. In this case I ‘just’ do my work ‘invisible’ until I become a ‘member’ → sgothel at gmail,.com, if it has to be a google account. This forum is fine ofc.

Regarding AWT - I like to avoid it at all costs to favor ie NEWT inclusive for input. This will allow the port to also work on ‘other’ VMs,

ie Dalvik/Android. I guess this will be an even more ‘challenging’ task here.



@EmpirePhoenix: I have to admit I haven’t looked to deep into LWJGL details yet. In general both are ‘just’ wrappers, sure

Lately we have added a more convenient deployment mechanism and focus on usability across devices.



One big difference between both GL ‘accessors’ IMHO is that JOGL uses GlueGen to [mostly] automatically generate the binding.

For example - if we find out a better technical way to deal with native memory buffers, we may simply introduce it in GlueGen

and generate the new code.



Your point with ‘how to use/cache NIO buffers’ and how to deal with such w/ lower level (LWJGL/JOGL) API is exactly one

motivation why I like to ‘help out’ w/ a JOGL backend - use-case driven enhancements.

I don’t quite understand your question completely w/o further details,

all I can say JOGL wrapped GL methods can be fed w/ NIO (direct and indirect) and non NIO buffer.



For sure, in cases where you slice buffers and have lots of CPU operations (ie. the ‘pmv’ matrix)

you like to use an array backed buffer,

see: PMVMatrix, JOGL source: http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/com/jogamp/opengl/util/PMVMatrix.java;hb=HEAD (don’t know if your forum cuts-out all links - so if you don’t see any, it did).



One example of manual optimized code path is ‘glMapBuffer()’, it uses an NIO cache for memory regions

and only creating a new direct NIO buffer if required. I am sure the more we dig into this task, the more both projects may benefit.

I would [love] to see my role sort of restricted in supporting JOGL, ie. enhancing both code path related etc.

Of course - to even get close to such a state, I guess I have to do the lovely work myself. Then we will see how it goes.

At least I get to know the details of jme3 … which is great after digging in an Ardor3D variant a few years ago

and to refresh my scenegraph knowledge. So I will do this work on the side with August 2012 as a demo date in mind.

[sgothel]

@EmpirePhoenix: I guess I see your point now. Sure, it depends on the use case (glMapBuffer(), or ‘streaming’ VBO/texure data).

Both items are already earmarked by Rami Santina (who wrote the GPU Curve rendering math) and myself, allowing huge data to be

streamed on devices w/ restricted resources (mobile). Actual use-case here is a CAD software, which uses JOGL.

Our intended solution is to write ‘another’ utility for [DMA] streaming data, probably using memory mapped files.

But sure, we could also use an explicit single cache. One such simple cache already exist in GlueGen, ‘CachedBufferFactory’.

The latter must be revised to allow all sorts of streaming, and it doesn’t reflect the PAGE_SIZE, alignments etc yet.

[Empire_Phoenix]

Actually I don’t exactly do a real streaming I have a tiled map that is prepared by background threads while idle or if to less processing power when needed. The ability to use one would make stuff like terrain a lot more itnresting tho.





Well the current problem i had was grassbatches,

I generate grass batches with a ground_cover model out of different stuff like grass, leaves, ect and batch small regions togeter, to allow fast rendering (in a background thread, for probably next needed batches)

Now when moving fast, like a racecar or similar, the amount of batches replaced every second hits thats limit (for now I use the probided destroy method, but wich works fine, but I still have a somewhat ungood feeling).



The problem here is the combination of that lwjgl uses only direct buffers(the current version forces you to use them for everything) with the issue of the gc doing a sloppy job freeing them.



Extract of that method, I guess you can understand what gives me the bad feeling.

[java]

Method cleanerMethod = toBeDestroyed.getClass().getMethod(“cleaner”);

cleanerMethod.setAccessible(true);

Object cleaner = cleanerMethod.invoke(toBeDestroyed);

if (cleaner != null) {

Method cleanMethod = cleaner.getClass().getMethod(“clean”);

cleanMethod.setAccessible(true);

cleanMethod.invoke(cleaner);

} else {

// Try the alternate approach of getting the viewed buffer

Method viewedBufferMethod = toBeDestroyed.getClass().getMethod(“viewedBuffer”);

viewedBufferMethod.setAccessible(true);

Object viewedBuffer = viewedBufferMethod.invoke(toBeDestroyed);

if (viewedBuffer != null) {

destroyDirectBuffer( (Buffer)viewedBuffer );

} else {

Logger.getLogger(BufferUtils.class.getName()).log(Level.SEVERE, “Buffer cannot be destroyed: {0}”, toBeDestroyed);

}

}

[/java]



A simple way to tell the underlying api to give me a directbuffer or to release it that works on all platforms would be a nice addition, without changing anything else.

[sgothel]

Doesn’t LWJGL allow you to use non direct NIO buffers’s, ie. with a backing array ?

For sure this should and could be handled on the application level, as long the objects lifecycle

can be properly negotiated with the lower APIs. Out glMapBuffer()'s NIO caching here is an example of whats missing,

properly releasing a cached instance / region in a deterministic way. But this example is unrelated I guess.

Depending on your CPU update processing you may use an NIO w/ a backing array, like our PMVMatrix.

Then you may have an NIO cache util handling all the reusage of the NIO buffers like our CachedBufferFactory.

Maybe we can enhance this class together ? I would like that.

The caching itself should solve your problem IMHO. But again, w/o knowing all the sideeffects (lifecycle, etc)

one cannot make a too bold statement here.

[sgothel]

NEWT: http://jausoft.com/blog/2010/11/28/newt-threading-overview/

and general abstraction ([NativeWindow], [JOGL], [NEWT, AWT, SWT]

and JOGL’s OpenGL profile handling is IMHO one of the strong points …



NEWT also allows you to render onscreen in it’s own thread,

where you shall use the AWT-EDT when using the native AWT peer.

Don’t know how this is handled in LWJGL.



I would say … JOGL is proven to be thread safe

and has some nice helpers like workflow listener models (GLEventListener)

and GL command injection to a rendering thread, etc.

But these things might not really matter in a higher level toolkit like jme,

I don’t know.



… just to give you a bit of an overview.

[normen]

Hey,

as Erlend pointed out, we want to avoid having multiple desktop renderers (a la jME2 – two half-broken renderers make one fully working one… not xD) and our abstraction layer for renderers is pretty thin, they basically have to reimplement everything. When gouessej started porting jME3 to JOGL2 he kind of insisted on extending the abstraction layer which might seem feasible when implementing a second desktop renderer but is completely not what we want.



Still, we are not completely sold on lwjgl and if JOGL2 makes it easier for us to support desktop GL then theres a valid chance we’ll switch over to that renderer. Given the issues we had with different aspects of lwjgl lately the moment might just be right ^^ For the “features” I guess we won’t have much use for them (except maybe the windowing part) as most of these things are handled on another level in jME3 (abstracted renderer for Android/GLES, no event based rendering). We really just need an “OpenGL wrapper”.



But yes, as you pointed out, it will most probably be most work for you as the amount of work in supporting two desktop renderers was already the biggest factor in the decision to drop JOGL (or lets say “one of the desktop renderers”).



The direct buffer issue is nothing we could do much about as it is. We are using direct buffers, period… This already implies all the “issues” with them and as long as we don’t change our API to not use direct buffers theres no use in thinking back and forth about solutions we cannot apply. So no need to make that a priority when doing something just yet.



Cheers,

Normen

[gouessej]

Hi

@erlend_sh said:
In order to make it into trunk, i.e. bundled by default with the jME3 SDK, you'd have to outperform LWJGL somehow.

In my humble opinion, that's not fair. We should not have to outperform our competitor in order to make it into trunk.

@normen said:
When gouessej started porting jME3 to JOGL2 he kind of insisted on extending the abstraction layer which might seem feasible when implementing a second desktop renderer but is completely not what we want.

I tried to ease the future maintenance of the renderers but if it was too heavy for you, you should have said it and I would have used a more traditional approach. Instead of doing that, some people simply decided that the JOGL support should be dropped.

@normen said:
Still, we are not completely sold on lwjgl

That's not what I felt when I worked on the both renderers based on JOGL in the past. I often have to undergo FUD campaigns against JOGL which is quite demoralizing. I'm very implicated in the support of JOGL in several APIs (engines, scenegraphs, etc...) and I'm still sad when I see that some people still say that JOGL is dead.

I'm sorry to say that but unlike Sven, I have compared LWJGL and JogAmp (JOGL + JOAL + JOCL) for years. The main difference is now very visible thanks or because of Minecraft, lots of GNU Linux users are forced to install its Windows version with Wine to work around some "problems" when using LWJGL with some combinations of VM (OpenJDK 1.7) and nvidia drivers. The next major release of LWJGL (LWJGL 3.0) will simply contain some new features already in JOGL (for example multiple screens support, SWT heavyweight canvas, some improvements in its native windowing system). As far as I know, JogAmp and LWJGL 3.0 will be extremely similar in term of features but not in term of reliability. I still have some dirty straight lines appearing on my desktop when I leave an application using LWJGL when I use a Linux distro with KDE 3. I still denounce this duplication of efforts. In my humble opinion, there is no need of 3 OpenGL wrappers for Java, even Google should have used JOGL instead of creating its own binding.

I will help Sven if necessary but only if the source code has at least a vanishingly small chance to be in the trunk. Best regards.

[normen]

All your arguments go against stuff we talked about years ago, none of our views on this changed. And we did communicate we don’t want the renderer to be abstracted to greater extent. We will not be an OpenGL wrapper testing suite, period. And this ”fairness” thing is just silly. I could just as well say its unfair you won’t let me screw your girlfriend. I have lots of arguments why it would be better if I did. Again, this is not about JOGL itself, its about having two desktop renderers. We want monogamy

[gouessej]

@normen said:
All your arguments go against stuff we talked about years ago, none of our views on this changed. And we did communicate we don't want the renderer to be abstracted to greater extent. We will not be an OpenGL wrapper testing suite, period. And this ”fairness” thing is just silly. I could just as well say its unfair you won’t let me screw your girlfriend. I have lots of arguments why it would be better if I did. Again, this is not about JOGL itself, its about having two desktop renderers. We want monogamy ;)

It is about JOGL itself, it harms the JOGL project because JMonkeyEngine is the most popular 3D engine written in Java. I don't want to harm the LWJGL project even though I clearly disagree with some of its maintainers. Currently, we have to advise JOGL users to use some other scenegraphs (Ardor3D, Java3D) because JMonkeyEngine 3 has no JOGL based renderer.

Sorry but is it time to laugh about this situation? Sven, Rami and the main contributors of JOGL 2.0 have done a great job, they have spent a lot of time on it. I have spent a lot of time in tinkering and contributing to several engines. Do you think I can appreciate your metaphor?

[normen]

I won’t discuss this again. You cannot just run around and demand from people to use your stuff, really, theres absolutely nothing justifying that or justifying that you blame us for not using every OpenGL wrapper on this planet. I don’t want to make fun of you, to me its exactly as in the analogy I used.

[gouessej]

@normen said:
I won't discuss this again. You cannot just run around and demand from people to use your stuff, really, theres absolutely nothing justifying that or justifying that you blame us for not using every OpenGL wrapper on this planet. I don't want to make fun of you, to me its exactly as in the analogy I used.

I don't demand anything but I don't see why JOGL would not be supported in JMonkeyEngine 3 whereas it is at least as reliable as its competitor.

[nehon]

@gouessej said:
Currently, we have to advise JOGL users to use some other scenegraphs (Ardor3D, Java3D) because JMonkeyEngine 3 has no JOGL based renderer.

Well the moment they are looking for an abstraction layer over JOGL they are not JOGL users anymore...Why would they care as long they'll never call JOGL methods anymore...

@gouessej said:
I don't see why JOGL would not be supported in JMonkeyEngine 3 whereas it is at least as reliable as its competitor.

Again...we have nothing against JOGL...but we don't want to have to maintain 2 renderers, period!
If we consider JOGL it will be for a switch... but then according to you it won't be fair for LWJGL....will you still claim it's not fair? i doubt it.

JOGL might be a great product, i honestly can't tell what are the pros of it compared to LWJGL. Right now switching to it would feel like a huge work for no gain.

[gouessej]

@nehon said:
Well the moment they are looking for an abstraction layer over JOGL they are not JOGL users anymore...Why would they care as long they'll never call JOGL methods anymore...

JOGL is used in various situations, sometimes with legacy rendering code in C/C++, sometimes with other applications like WorldWind, sometimes they mix Ardor3D with other intermediary level APIs like Jzy3D. Moreover, for unknown reasons, there are some differences of speed between JOGL and LWJGL, there are some differences in the implementation of their respective native windowing systems. These differences can affect the behaviour of their applications.

Looking for an abstraction layer to ease the implementation of 3D features does not mean that you don't mind what is used underneath even though you avoid to call JOGL methods because the reliability of the whole application depends on all its layers, not only the high level scenegraph.

Actually, I'm not a professional game programmer, I program a game as an hobby, I'm an engineer in computer science, I work in 2D/3D visualization. that's why my vision is not only "gaming-oriented".

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

@nehon said:
Again...we have nothing against JOGL...but we don't want to have to maintain 2 renderers, period!
If we consider JOGL it will be for a switch... but then according to you it won't be fair for LWJGL....will you still claim it's not fair? i doubt it.

JOGL might be a great product, i honestly can't tell what are the pros of it compared to LWJGL. Right now switching to it would feel like a huge work for no gain.

I don't want to harm anyone and I was ok to keep 2 renderers but I understand a bit Normen's position. There are pros and cons on the both sides.

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.