Are NURBS supported by jogl yet? (I’ve tried running some of the nurb functions like glu.gluNewNurbsRenderer(); but seems like it “cannot resolve symbol” and I imported the
net.java.games.jogl.GLU; and net.java.games.jogl.GLUnurbs; classes ) If so, do I first create the a nurbs variable with " GLUnurbs nurbs; " and then nurbs = glu.gluNewNurbsRenderer(); ?
???
-Thanks in advanceI was working on implementing (read porting) nurbs for use in jogl, but I haven’t had much time lately…
big deep breath
Ok. I know this might seem pushy and it realy isn’t cos I understand the chaotic nature of the world and how that interplays with the transdimentional soup of life… gibbers inanely for a while.
exhales
… how’s the NURBS port coming along? 
is there an approximate ETA?
Thank you.
Progressing slowly but steadily. Somewhere around 30% done now I think.
I think I’m at 50% now excluding testing.
nurbs is a LOT of code to port 
tesselator was much easier
I haven’t had much time lately to continue working on the nurbs port and I don’t see me having much time in the immediate future. If anyone wants to continue where I stopped, let me know and I’ll send you the code. Warning upfront: it’s not in a working or compiling state yet, so there is still quite some work to be done…
I’ve emailed Pepijn about possibly picking up his GLU NURBS port to Java. I could have sworn I saw at least a partial port of the NURBS code in the LWJGL source base a couple of months back but seem to be misremembering. Nonetheless the LWJGL team has done a good job of porting over some of the key functionality in GLU to Java and I think we should incorporate this code (with proper attribution) into the JOGL source base and build on it to completely eliminate the native code dependence for GLU.
Ken,
Just wanted to check on your last statement there. You’re wanting to get all of GLU into a pure-java implementation, and not GLUT?
Yes, GLU, not GLUT. The LWJGL team has made good progress in rewriting some of the core GLU functionality like lookAt and mip-map construction in Java. We have a port of the GLU tesselator code done by Pepijn Van Eeckhoudt and Nathan Burg; I think the NURBS code is the only other major piece missing. If we assembled all of these pieces we could drop the reliance on the native GLU library.
I think going for a full java GLU port would be a good idea. That would give some guarantees with respect to the quality of the GLU implementation across platforms. Also GLU isn’t hardware accelerated anyway so there should be no noticeable performance loss. It does add some maintenance burden for the jogl developers though.
Ok, we have written the mipmap and lookAt code many times over. I’ll see which set of code would be the best to pull from and see how it maps to the GLU calls. May be able to send something in your direction pretty quickly on that. NURBS code is a little more tricky due to the evaluator callback setup IIRC. Never used it directly as I always found it to be flaky - hence writing our own NURBS library.
Sounds great. Given that GLU hasn’t changed in years I think porting it to Java will actually be less of a maintenance burden than it currently is, where we get impossible-to-reproduce bug reports every couple of months on random Linux distributions.
I would like to start a discussion about how the GLU stuff should be implemented. Quadrics in lwjgl for instance have been turned into classes. While this isn’t a bad thing, it does break compatibility with the GLU specification. Personally I think jogl should at least have all the glu methods available in some form.
I can’t speak for the rest of the lwjgl team, but I am fairly certain that we would prefer to work together on the glu/nurbs port. Maintaining two versions of the same thing is just silly. I am indifferent to whether or not to use objects for Quadrics.
/matzon
Collaborating on the GLU port sounds great to me. I agree with Pepijn that we should stay close to the GLU API, meaning that we should have as many of the gluXYZ functions available as possible. Take a look at the GLU tesselator port in the JOGL source base; I’m planning to use that style to translate the C callbacks to Java for the GLU NURBS port. FYI, I’ve been looking through that source code and started porting a few classes over; it looks pretty straightforward so far, though I think it might get complicated once I get into the main code.
Ken,
I have the gluLookAt code done. I know I need to sign the JCA stuff, but where should I put the code? A RFE in the bug tracker attached as a patch, or a link to a zip file or???
Thanks for working on this. Please file a “patch” (as opposed to an RFE) with the JOGL Issue Tracker and attach the zip archive to the report.
Did you look at the LWJGL team’s port of this portion of GLU? It was my understanding that they had ported more than just the lookAt code, but instead the entire projection sub-library (though I don’t know what other routines use it).
No I didn’t. We have our own implementation of these methods that we’ve been using for the past year or so. I know what’s in there and since it is our code, we can deal with the copyright and licensing issues easily.