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)

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.

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

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.

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.

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 )

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.

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

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?

[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

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org