GLU

[erikd]

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)

[Mojomonkey]

Quadrics would be nice.

[elias]

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

Games published by our own members! Check 'em out!

[Middy]

well I actually made my own sphere function..humm so maybe not...

[Mac_Systems]

Hi,

i think GLU would be great, maybe we can provide
even more Objects like Torus , Torusknot  etc...

- jens

[erikd]

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:

1   2   3   4   5   6

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:

1   2   3   4   5

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?

[fbi]

First of all I believe that having GLU is VERY useful...as Elias pointed out having gluPerspective() and the others is very useful  
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  

[princec]

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

[erikd]

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.

[wiesi]

I think gluBuild2DMipmaps would be nice too.

Games published by our own members! Check 'em out!

[erikd]

I think gluBuild2DMipmaps would be nice too.

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.

[erikd]

Quadrics are done  

Currently, code for drawing a sphere looks like this:

1   2   3   4   5

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.

[erikd]

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  
- 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

[princec]

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

[erikd]

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

[princec]

I think the native GLU will be gone in 0.9.

Cas

[erikd]

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   *

[Matzon]

your GLU will replace the native version - that is, if you want it to

[erikd]

of course  

[Matzon]

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...

[Matzon]

k, so I researched a bit - when you mentioned mipmap.c, I immediately thought of Mesa, but I found http://ftp://oss.sgi.com/projects/ogl-sample/download/ to contain SGI's reference OGL/GLU/GLUT/GLW/GLFONT implementation, which afaik, has a compatible license.

[erikd]

Okay, I'll look at the open GL sample. Maybe the SGI code also doesn't have the bugs in the quad functions.
I think I already downloaded the source, but chose Mesa without considering the license...
But what if the GLU port is distributed seperately from LWJGL, does lgpl still not allow it?

(damn, I almost finished porting mipmap.c which is not as straighforward as the other functions  )

[elias]

It would still be a hassle now that GLU will be entirely replaced and not just the more exotic functions like quadrics. I'd personally like to see the code in LWJGL itself.

- elias

[Matzon]

yeah, I'm with elias on this one too. LGPL and BSD don't really match, and I'd prefer something like GLU to be closely tied to LWJGL.  

If you decide this way, we can add you as an developer and you can work directly off cvs.

[princec]

If Erik's hand-ported this code to Java, in other words, written it himself using Mesa and other sources as a reference, then I believe he's entitled to give it whatever license he wants because it's his work. The quadrics stuff is certainly unique.

Cas

[Matzon]

Somewhat true, problem is that when you look at some GPL/LGPL code you could potentially have problems arguing that the code itself is not copied, since some methods might be very similar.
Basing an implementation on some other less restrictive license will not carry any problems, and you won't have to argue at all ('cept perhaps copyright).

Basically, I avoid L/GPL like the plague when I do non GPL code, simply because of it's (quote microsoft) "viral nature".

[erikd]

yeah, I'm with elias on this one too. LGPL and BSD don't really match, and I'd prefer something like GLU to be closely tied to LWJGL.  

If you decide this way, we can add you as an developer and you can work directly off cvs.

I will use the SGI sample as reference and start over (should be not too much work I suppose), so that my code can closely tied to LWJGL while avoiding problems.
The Mesa code is not very good anyway (quadrics are buggy, various functions are incomplete and untested, development on Mesa GLU stopped).
I'd like to follow code conventions in LWJGL as well, so you guys might want to take a look before checking it in CVS. We also might want to discuss package names and such (org.lwjgl.glu ?).
Most of the functions will be pretty much GLU compatible, I'm thinking about writing GLU compatible wrappers for the quadrics stuff. Which I would personally never use, but might be handy anyway if you want to use them in the ugly old fashioned GLU way. What do you think?

Erik

[erikd]

Oh my god, mipmap.c in SGI's glu is 274kb as opposed to Mesa's 20kb!  

* erikd bravely started rewriting anyway... *

EDIT: * ...thinking every developer using 'goto' should be shot   *

[Matzon]

Oh my god, mipmap.c in SGI's glu is 274kb as opposed to Mesa's 20kb!

!!!
Well, then - hang on a bit I'll verify license issues with #gnu, they might be better informed. Stay tuned...

[Matzon]

hmm, so it was late, everybody was sleeping - I wil ltry again tomorrow to get a more thorough answer

[00:23:28] <marco_g> IIRC rewrite (as in translating to another language) doesn't mean anything for copyright law.

[00:23:56] <foolip> ooops, I didn't go to sleep. ok, but in any event, I don't think the linking method could matter. what matters is if you actually use the LGPL code (for example if you invent a C->Java translator and run Mesa through, you obviously couldn't claim the copyright to it)

[00:26:48] <foolip> If I translate a book from english to swedish, I probably still won't be allowed to sell that without the original authors consent. with a computer program, you can't just translate each line to another, so it all depends on how tightly you follow the original I guess. If you're just sensible and don't do anything stupid I doubt the Mesa people will give you any troubles, they're good guys. Perhaps you should just ask them if they'd allow a Java trans

[00:26:49] <foolip> lation to be BSDish no matter, in that case you wouldn't have to worry at all.

curiously, they answered copyright questions, when all I wanted to get answered were license issues - oh well