I’m thinking about porting GLU to java as an add on for LWJGL. Maybe just a partial port, or (if really needed) a complete port. So if you need GLU functions again, please state which functions.
If there’s no need, I’ll just create something for myself since I kinda need some functions in my own games (just spheres and cylinders)
Quadrics would be nice.
That would be a nice addition. I’d especially like to have gluPerpsective and friends ported too, but that’s just because I’m an evil wizard with plans to zap LWJGL dependence on the native GLU library.
- elias
well I actually made my own sphere function…humm so maybe not…
Hi,
i think GLU would be great, maybe we can provide
even more Objects like Torus , Torusknot etc…
- jens
Ok, so I started the port and let’s see how it goes.
GLU is very C oriented and much non-OO. I’d like to change that a little so that it becomes more java like.
For example code like:
int quadric = glu.newQuadric();
glu.quadricNormals(quadric, GLU.SMOOTH);
glu.quadricTexture(quadric, true);
glu.quadricOrientation(quadric, GLU.OUTSIDE);
glu.quadricCallback(quadric, GLU.ERROR, "quadricError");
glu.sphere(quadric, 1.75, 16, 8);
would become something like:
Quadric quadric = new Quadric();
quadric.setNormals(GLU.SMOOTH);
quadric.setTexture(true);
quadric.setOrientation(GLU.OUTSIDE);
quadric.sphere(1.75, 16, 8);
I don’t know yet if I’ll do the call back. Maybe I’ll just throw exceptions…
I could als do the quadric.setSomething() in the constructor.
Thoughts, comments?
First of all I believe that having GLU is VERY useful…as Elias pointed out having gluPerspective() and the others is very useful ;D
Anyway I think that to keep in sync with the current LWJGL notation for GL you should plan something like GLU.gluPerspective etc., where each method is static.
That should enable us (when JDK 1.5 will be out) to just call gluPerspective() in the good old C-style fashion
Seeing as it’s going to end up looking very unlike the C GLU library, maybe we should call it something else?
We’re also mulling the idea of a LWJGL Utils library as it is, with stuff like textures and displaylists etc etc encapsulated into objects, to make life easier for everyone.
Cas
Hmyes good point…
Thinking about it, I don’t really like going for a straight GLU port, because it will make code unnecesarily dirty even if it will make porting other C code using GLU a (very) little bit easier.
So maybe this GLU ‘port’ should be integrated in this LWJGL Util lib you reckon? Sounds like a good idea to me.
I think gluBuild2DMipmaps would be nice too.
[quote]I think gluBuild2DMipmaps would be nice too.
[/quote]
They’re still in lwjgl 0.8 I think ???
If the lwjgl devs want to separate GLU from lwjgl, I will probably still add it.
Quadrics are done
Currently, code for drawing a sphere looks like this:
sphere = new Sphere();
sphere.setNormals(GLU.GLU_SMOOTH);
sphere.setTextureFlag(true);
sphere.setOrientation(GLU.GLU_OUTSIDE);
sphere.draw(1.75, 16, 8);
Sphere is a subclass of Quadric.
So code now looks slightly different from real GLU.
If somebody wants to use the current GLU quadric functions, just mail me and I’ll send it to you along with source.
I’ll add more GLU functions later and hopefully complete the thing fully. I’ll be working more on CT again so progress will probably be slow. I know only the quadrics is very little (actually just 1 hour of work, really), but those were the things I needed in CT so I ported them first.
Be aware of a few things:
- It depends on LWJGL 0.8
- It just supports sphere, cylinder, disk. Partial disk is not yet ported.
- Its almost untested except for the cases I use in Cosmic Trip (textured spheres and cylinders). Well, ‘it compiles’ is a good test result isn’t it ;D
- It is a port of Mesa’s GLU functions, which have some known bugs related to normals pointed inwards. I bumped on those bugs in Cosmic Trip where the tunnel would not appear. Workaround was to disable backface culling when rendering cylinders with normals pointed inwards.
- See the posts above on how to use it.
- I’m thinking about replacing the doubles with floats. It would save a lot of casting in the code and I doubt if doubles are really needed here.
Erik
Go for floats. We deliberately axed the double methods in LWJGL because we wanted a gaming API, and doubles don’t really have much of a place in games.
Cas
Status update:
- replaced doubles with floats in the quad functions
- added gluLookAt
- added gluOrtho2D
- added gluPerspective
- added gluPickMatrix
- added gluGetString
most of these might still be in LWJGL, but they might come in handy when the LWJGL devs do decide to axe glu dependance.
Again, anyone is more than welcome to test them (just mail me).
Erik
I think the native GLU will be gone in 0.9.
Cas
Does that mean my GLU port will become useless because there will be a substitute or will my GLU port become the substitute?
*erikd staring at mipmap.c : *
your GLU will replace the native version - that is, if you want it to
of course
What license is your GLU library? If it’s based on Mesa (and thus lgpl) we won’t be able to include it in the cvs I am afraid - at least without issues. I don’t know how we would solve this easiest…