GLU

[Matzon]

Ok, so I talked with some people and seached a lot - basically, lgpl is bad in conjunction with LWJGL.
1 - Using the import statement(!) against a LGPL library is enough to invoke it.
2 - If making import statements is enough to "infect" surely rewriting something once LGPL would be even worse.

Some info:
http://article.gmane.org/gmane.comp.jakarta.poi.devel/5900

Oh, and the guys in #gnu @ freenode.net are not particularly friendly regarding license issues:

[17:55:25] * mortal changes topic to 'GNU: It's all about software freedom || Consult your lawyer in questions related to licensing of Free Software'

I don't really know where to go from here, GLU would be nice - but at the price of a 200 kb mipmap file - thats a bit daunting!
I'll see if I can find another "free" implementation which is more simple.

[erikd]

Hi Matzon

Thanks for doing the research  
I was afraid of this. In the meantime, I will just do some research using the sources I have now so I can do a proper rewrite without violating licenses. As I see it, using some techniques to write my own code is ok. The SGI code is very complicated because they cover all cases while maybe it's not necessary for LWJGL (being targeted to games and all). I mean, I don't think we have to support all pixel formats and optimize for openGL version 1.0 do we?

Erik

[Matzon]

Well, basically I'd just start out with the most simple cases, and then progress slowly from there - no need in optimizing each and every case, and doing all methods in fell swoop. I'm in no hurry

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

[elias]

You can safely assume GL 1.1 and an RGB pixel format, because that's the minimum LWJGL runs on. So yes, there's probably a lot to carve away.

- elias

[erikd]

Can I also safely assume type GL_UNSIGNED_BYTE or is anyone frequently using other types? (I only had to use this type so far).

FYI, I got mesa's mipmap function working for GL_UNSIGNED byte types, using point sample scaling. It doesn't look very good because of the simple scaling algo, but I can use what I have now to rewrite it using some of Mesa's techniques. That would be okay, right?

EDIT: rewrote scaling, so everything now looks silky smooth  

And do we really need gluBuild1DMipmaps? I couldn't think of one possible use for it in games...

[cfmdobbie]

It's about as useful as a chocolate glutSolidTeapot.  Ditch it.

[erikd]

It's about as useful as a chocolate glutSolidTeapot.  Ditch it.

That's what I thought.

The current status is that I replaced the glu functions with new ones ported from SGI, except for:

* mipmaps are now just partially ported. I rewrote scaling and it looks now much better than the original mesa code. I also fixed 1 or 2 bugs in the mesa code here. I also did some refactoring in the code so there's just very little mesa code left. Is this sufficient to call it our own code, you reckon?
* quads are also still partially from mesa. I looked in the SGI code and it's *very* similar (it's really almost the same). Since I refactored it to make it OO code, you think it's still violating the LGPL license? I mean how many ways are there to draw a sphere, really...

Now I just have the tesselation code and the nurbs code left. Which is *lots* of code to port. Anyone using that?

Erik

[pepijnve]

I already ported the tesselation stuff from the SGI sample implementation some time ago. It's integrated into jogl...

[oNyx]

[...]
Now I just have the tesselation code and the nurbs code left. Which is *lots* of code to port. Anyone using that?

Well, I was about to use the tesselation stuff... but I just found that it isn't there... oh well :-/

Once again it's time to reinvent the wheel... or switch to C/C++ or JOGL...

Crap :l

[erikd]

Typical how java developers often claim they are switching to C++ or C# whenever there's a little set back ... :-/

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

[oNyx]

Typical how java developers often claim they are switching to C++ or C# whenever there's a little set back ... :-/

Nah. I ment for that part (level building process).

I have to do something about this and the options are:

-more timeconsuming level building (won't work)
-build that part by myself
-port something that does the trick
-do that part in jogl
-do that part in c/c++

Well, it won't convert me into a C/C++ guy... it's just another minor annoyance :]

[erikd]

Of course.
Never mind me, that was just a comment from somebody with a hangover