erikd
|
 |
«
Posted
2003-12-15 16:38:49 » |
|
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
|
 |
«
Reply #1 - Posted
2003-12-15 16:47:15 » |
|
Quadrics would be nice.
|
Don't send a man to do a monkey's work.
|
|
|
elias
|
 |
«
Reply #2 - Posted
2003-12-15 18:29:52 » |
|
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
Junior Devvie  
Java games rock!
|
 |
«
Reply #3 - Posted
2003-12-16 09:29:08 » |
|
well I actually made my own sphere function..humm so maybe not...
|
When do I get my makeMyGameAsILike() extension?
|
|
|
Mac_Systems
Junior Devvie  
I love my Java
|
 |
«
Reply #4 - Posted
2003-12-16 17:37:31 » |
|
Hi,
i think GLU would be great, maybe we can provide even more Objects like Torus , Torusknot etc...
- jens
|
|
|
|
erikd
|
 |
«
Reply #5 - Posted
2003-12-19 07:41:18 » |
|
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
Senior Newbie 
|
 |
«
Reply #6 - Posted
2003-12-19 08:25:06 » |
|
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 
|
PhD Student@Virtual ArtificiaL Intelligent Systems (VALIS) Laboratory
Fatti non foste a viver come bruti...ma per seguir vertute e canoscenza.
|
|
|
princec
|
 |
«
Reply #7 - Posted
2003-12-19 09:56:09 » |
|
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
|
 |
«
Reply #8 - Posted
2003-12-19 10:29:04 » |
|
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
Senior Newbie 
Java rulez!
|
 |
«
Reply #9 - Posted
2003-12-20 05:25:50 » |
|
I think gluBuild2DMipmaps would be nice too.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
erikd
|
 |
«
Reply #10 - Posted
2003-12-22 21:04:21 » |
|
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
|
 |
«
Reply #11 - Posted
2003-12-22 21:08:52 » |
|
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
|
 |
«
Reply #12 - Posted
2003-12-30 17:54:39 » |
|
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
|
 |
«
Reply #13 - Posted
2003-12-30 20:12:29 » |
|
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
|
 |
«
Reply #14 - Posted
2004-01-06 18:00:50 » |
|
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
|
 |
«
Reply #15 - Posted
2004-01-06 18:31:58 » |
|
I think the native GLU will be gone in 0.9. Cas 
|
|
|
|
erikd
|
 |
«
Reply #16 - Posted
2004-01-06 18:43:47 » |
|
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
|
 |
«
Reply #17 - Posted
2004-01-06 19:41:00 » |
|
your GLU will replace the native version - that is, if you want it to 
|
|
|
|
erikd
|
 |
«
Reply #18 - Posted
2004-01-06 20:13:13 » |
|
of course 
|
|
|
|
Matzon
|
 |
«
Reply #19 - Posted
2004-01-07 03:41:18 » |
|
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
|
 |
«
Reply #20 - Posted
2004-01-07 04:50:12 » |
|
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
|
 |
«
Reply #21 - Posted
2004-01-07 05:20:54 » |
|
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
|
 |
«
Reply #22 - Posted
2004-01-07 05:42:46 » |
|
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
|
 |
«
Reply #23 - Posted
2004-01-07 06:06:03 » |
|
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
|
 |
«
Reply #24 - Posted
2004-01-07 06:42:36 » |
|
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
|
 |
«
Reply #25 - Posted
2004-01-07 07:30:15 » |
|
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
|
 |
«
Reply #26 - Posted
2004-01-08 06:19:52 » |
|
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
|
 |
«
Reply #27 - Posted
2004-01-08 16:00:56 » |
|
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
|
 |
«
Reply #28 - Posted
2004-01-08 19:31:29 » |
|
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
|
 |
«
Reply #29 - Posted
2004-01-08 21:07:21 » |
|
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
|
|
|
|
|