I was learning JOGL by analysing the source code of Xith3D, but I found that errors are reported by Eclipse.
And I found jME is similar and none errors are reported by Eclipse. It absoulutely quicken my study.
So I hope jME can ported to JOGL soon.
Yes, jME could be ported to JOGL in a reasonable time frame. Though it is not the current task of any developer and there is no milestone defined for it yet.
A jME user has already started a JOGL port - see this thread. You might me interested in helping him with that unofficial port.
Actually, what irrisor says is not exactly true… jME version .12 is when we are set to officially add JOGL support. That said, his suggestion regarding helping in the community is a great one. 
renanse said:
Actually, what irrisor says is not exactly true... jME version .12 is when we are set to officially add JOGL support.
oops
Hey guys,
Not read anything about this in a while, the thread linked to above seems to have been dead for a bit over a year.
So what's the state of the JOGL port? I'm very keen to get one in place if it allows me to render JME directly into the back buffer of a JPanel (as per the latest versions of JOGL and Java), so I'd be happy to help.
Thanks.
Personally, I see it as a waste of time until 1.0 comes out. There's still a few major renderer-facing things (especially related to shaders) that are still in development. Also officially supporting two renderers seems like a time sync that would require a dedicated person.
That said, if you want to do it… :) There's been a lot of old work done in this area, which could help.
I think the major benefit comes from the fact that JOGL might actually become part of the JVM in the not so distant future, and if this happens then the openGL calls will no longer require the JNI and performance should increase massively.
I would like to help project out as a whole, though. Is there by any chance a to do list?
afaik, there are no plans to add it to the JVM. Ken has said that himself.
Furthermore - any inclusion WILL NOT in any way speed up anything.
At the risk of sounding like a complete fool… Ken who?
I'm fairly sure that Chris Campbell mentioned in his blog that it might happen.
Ken Russel, the main guy behind JOGL
As the JOGL project lead I have been resisting putting JSR-231 into the core Java SE distribution. Java SE has become a large monolithic system and continuing to put more into it only exacerbates the problem. JOGL can be effectively distributed to end users as a standard extension in both Java Web Start applications and applets with no manual installation, so I don't see a strong reason to bundle it into the core APIs.
and I totally agree with him
what's the point of JOGL when we have lwjgl, and they both use OpenGL so it's the same.
Maybe if it was something like OpenGL and DirectX it would make sense…
just a waste of time if you ask me.
Seems like a natural progression to me.
J2SE already contains an openGL implementation (Java2D sits on top of it) and there’s currently a lot of work going in to using JOGL to speed up Java2D rendering (which it does: http://weblogs.java.net/blog/campbell/archive/2007/04/index.html). If you use a flag you can enable this in the latest builds. Probably just a matter of time until they just sit Java2D on top of JOGL openGL implementation as standard.
As voiced by the general opinion in this thread, there really isn't a reason for a JOGL version except that it's 'cooler' because Sun is behind it.
keeskist said:
As voiced by the general opinion in this thread, there really isn't a reason for a JOGL version except that it's 'cooler' because Sun is behind it.
Me, I see a reason: JOGL integrates well with Swing by providing a JCanvas while LWJGL doesn't and I really need a JCanvas.
the JMECanvas provided by LWJGL *IS NOT* a lightweight swing component at all, please stop to write everywhere that JME integrate well with swing, it is not exact.
Is anybody working on a JOGL display system for JME right now? I am ready to help if it can be done within 3 working days.
missed one reason: android (meant to be close enough to the jsr to be pretty trivial to port, spec no finished yet).
Seriously though, I reckon it'd be an interesting excercise… putting a JOGL renderer into cvs (doesn't have to be a complete commit, as far as I'm concerned, just a 'work in progress')
Anyway, we still have JOODE in jmePhysics, which is trashed to a major degree.
I would expect it to be a little less than trivial though - there are alot of jme interfaces to get working (renderstates, for example), and the current architecture of the display system is geared towards evil static methods.
Is the display system getting a re-work for the 2.0 release? (which I'll assume isn't vapourware ;) )
If so, it really will be easier to wait (just make sure you get rid of as many static methods as possible).
If not, well, there isn't anything to lose.
I'll help (after next friday, I'm looking for a contract)… Hell, I'll even try and get the ball rolling (unless someone beats me to it).
in Features http://www.jmonkeyengine.com/jmeforum/index.php?board=6.0 post up some stub code. Action generates results, talk generates talk.
==> So believe me when I post code, not when I say I'll post code…
When the source for 2.0 is released you are welcome to submit patches against that.
renanse said:
Personally, I see it as a waste of time until 1.0 comes out. There's still a few major renderer-facing things (especially related to shaders) that are still in development. Also _officially_ supporting two renderers seems like a time sync that would require a dedicated person.
That said, if you want to do it... :) There's been a lot of old work done in this area, which could help.
Renanse, I am willing to try it. But before I start, I would like to know if you are ready to accept any patches that may be needed to make JME not LWJGL-specific: If I start to write a JOGL display system and it can't be commited on the main repository, then I will have to integrate each new change made on the main repository on the one in my computer in order to provide my company the latest bug fixes, and that's painful.
So .. are we ready to make changes ?
(Say yes, please :))
If no, then I can't choose JME for my tools .. I will have to move to another engine that is compatible with JOGL and that's also painful because I will spend some time to make the switch.
renanse said:
When the source for 2.0 is released you are welcome to submit patches against that. :)
May I ask when the source for 2.0 is supposed to be released?
Edit: I would like to make sure that you understand that the patches I wish to post will not contain any JOGL related code but will only contain refactoring operations of JME in order to make it more renderer-independent. This would let me easily maintain the JOGL display system that I will have on my side and integrate into it the changes that you will make on your repository, until you eventually decide to add my display system to your code base.
karmaGfa said:
May I ask when the source for 2.0 is supposed to be released?
There is no firm date quite yet, mostly because there is a big chunk of the code involving states and shaders that Mrcoder and I are working on rewriting. We want to finish that before putting things up. He's in the middle of moving to the states, but we should pick back up on that in full earnest within 10 days.
renanse said:
... we should pick back up on that in full earnest within 10 days.
I took a look at the source code, and I feel (and fear) that there is a lot more than just add support for JOGL to solve my problems. There is also the support for multiple JPanel that is needed and now I realize that it involves many many changes .. I am not sure if I can do it on time: I need to show a demo in 7 days.
I think I should switch to an alternative scene graph API for now, in order to not let the rendering stop me in the development of my tools. Once the support for Swing and the multiple JPanel will be implemented jMe, I might port my tools back to it.
Conclusion: I won't do the JOGL as I planned, I choose the plan B. Sorry.