Want to Port OpenGL 3D App to JOGL …
I’m currently using an old binding gl4java.
It’s a 3D modeling application called ManifoldLab.
I want to port to JOGL so that I can move to Linux, and OS X more easily. gl4java has been a little problematic (only a little). I just want to porting to be 100% reliable and easy.
Any advice ?
Heres a DIVX Video (nicely authored and compressed)
Application in action … needs JOGL port.
http://ggaliens2.com.winhost3.atlantic.net/temp/COLOR3.AVI
If you’re already using gl4java, you will likely find a port to JOGL pretty straightforward. Just give it a go and ask questions if you get stuck.
I’ll give it another go pretty soon. I tried the migration a year ago and had some kind of issue.
A little off topic … bit not too much …
Would anyone know why or when Linux/OpenGL would give me back 1.0 - 1.0 from gl.glGetFloatv(g.GL_POINT_SIZE_RANGE, f )
???
This is a problem I’m having with Linux and gl4Java rightnow. I wonder if it would go away if I had Linux/JOGL.
I need to draw big fat points.
I did try disabling point smoothing.
Can’t help you with gl4java. All I can say is try jogl for a simple point drawing application and if it doesn’t work post here and someone will be able to give you an answer.
OK … Now I remeber a little about what I didn’t like about JOGL … or what I needed to overcome …
The fact that GLCanvas is final. This is not the case with my current API. I’m not sure how to add new behaviors to my canvas if it’s final.
Can you provide some basic advise here ? I’m probably just being thick-headed. Like I want to override reshape and more importantly display methods.
Please advise.
OK … my BAD Scratch this request … I read the docs after I jumped the gun. I need to add a Listener to the final object. OK … I can do that !
Gregory … can you tell me why there’s no glj GLContext available in JOGL ?
Or is there ?
My old implementation used it.
At top of thread, I’ve provided a link to an AVI depciting some neat features of my 3D Modeler’s UTILITY. I really think it’s worth a look. Eventually, I think I can convince you that having ManifoldLab JOGL based would be a nice endoresement for JOGL.
I just need to do a little more clean up in preparation for porting. I started yesterday and found I had many unwanted dependencies that made the port harder. So I’m doing some clean up first.
Source code for ManifoldLab is available on request.
As one of the GL4Java developers a couple of years back, I found that many of the programming errors that came up on the mailing lists were due to the fact that GL4Java exposed the notion of the GLContext and had two ways of performing drawing: subclassing GLCanvas and using the GLEventListener interface (which I added to that binding). In JOGL we tried to simplify the API and implementation by keeping the GLContext internal to the implementation and providing only one mechanism for drawing via the GLEventListener API.
Some of these design decisions are being revisited in the JSR 231 expert group, but work is still in progress there (and I’m not privy to the progress) so I’ll refrain from commenting further.
It should be possible to implement all of your existing GL4Java-based functionality with an appropriate GLEventListener and moving code around. For example, any code that went into your subclass’s reshape method should go into your GLEventListener’s reshape method. See the JOGL demos at http://jogl-demos.dev.java.net/ for some relatively advanced example codes such as using multiple off-screen pbuffers.
Ken … from what you say … I could get my code that much closer to ported (to JOGL) by using the GLEventListener in gl4java ? Right ?
I’m a big fan of making changes that permit the system to continue functioning. Then maybe the smallest possible leap into the JOGL unknown.
In this way … I change only a little at a time … my program is only a little tiny bit borken if at all during the port ?
Make sense ? I hope so.
If you use the GLEventListener mechanism in GL4Java then your code should run almost unmodified under JOGL. All you should have to change are the package names.