Can you give a quick comparison to jPCT? (I'm guessing DzzD has software anti-aliasing, jPCT doesn't)

I think that a good point for JPCT is that it is more mature than 3DzzD (opensourced earlier), 3DzzD have a lot of dead or dirty code, anyway I am not really aware of JPCT features so I can only give you some of 3DzzD features :

I am not really licensing pro , what good in BSD ? I choosen LGPL as it seem that it enable closed source aswell as opensource ? no it was looking very open for me.

GPL - anything using your library has to also be released as GPLLGPL - any improvements made to your library have to be released as LGPL, but simply using the library has no restrictionsBSD - Everyone is free to do whatever they want with your code, as long as they give you attribution.

If you want to maximise the number of people using your code, I'd go for BSD

it is also common in java land to add a classpath exception to the GPL, e.g OpenJDK is GPLv2+cp ex and even shipped with fedora. NetBeans RCP is also GPLv2+cp ex and used in commercial applications (which are usually not GPL).

yes, there is no problem in using LGPL API in closed source, maybe you cannot pickup classe here and here but you can modify & use the API in closed source and use license of your choice for your product. I found that LGPL is not really restrictive but if eard that it is too much restrive I will think about releasing using another license.

it is also common in java land to add a classpath exception to the GPL, e.g OpenJDK is GPLv2+cp ex and even shipped with fedora. NetBeans RCP is also GPLv2+cp ex and used in commercial applications (which are usually not GPL).

Afaik this does only mean, that you can link with a BSD licensed code in a GPL project, but not the other way around. As soon as you are using a GPLed class in a non GPL app you can't publish your work without relicensing it to GPL. That doesn't hold true for LGPL however, which is fine in most circumstances.

Afaik this does only mean, that you can link with a BSD licensed code in a GPL project, but not the other way around. As soon as you are using a GPLed class in a non GPL app you can't publish your work without relicensing it to GPL. That doesn't hold true for LGPL however, which is fine in most circumstances.

yes you are right, i had the "other way around" in mind. But it should be fine to link from a BSD app to a GPL lib with classpath exception. GPL with classpath exception is probably better suited for java aps compared to pure GPL since defining "linking" in java is quite tricky .

Licensing in general is IMO one of the most annoying parts of software engineering :/

There is no problem with LGPL and linking in Java. See this article. I'm not sure why classpath exception was invented in first place, probably that it's slightly less restrictive than LGPL. On the other hand it's non-standard to GPL, so while it matches GPLv2 wording it might have problems with future versions. This isn't problem for Sun because they removed ability to use it with any future version of GPL anyway, so linking with GPLv3 code is prohibited.

Anyway, back to topic. Thanks a lot for making the open source version I'm looking forward to use it in JBullet's applet demo instead of my simple software renderer. I need to have OpenGL compatible renderer so probably modifications or alternative rendering API will be needed to be developed by me, that's reason why I couldn't use jPCT at the time. And your renderer seems better too

Anyway, back to topic. Thanks a lot for making the open source version I'm looking forward to use it in JBullet's applet demo instead of my simple software renderer. I need to have OpenGL compatible renderer so probably modifications or alternative rendering API will be needed to be developed by me, that's reason why I couldn't use jPCT at the time. And your renderer seems better too

thanks,

first of all I apologize for the dirty code but it has been a kind of research project for me for some years now, so cleaning it to a nice OO project wasn't so easy, and there is still a lot of works to do in several classes.

3DzzD have interchangeable 3d renderer, for now there is 2 renderer : one for software & one for hardware (JOGL), it should be easy to create your own one by copying the existing JOGL renderer (the 3DzzDExtensionJOGL project in the devkit).

first of all I apologize for the dirty code but it has been a kind of research project for me for some years now, so cleaning it to a nice OO project wasn't so easy, and there is still a lot of works to do in several classes.

No need to apology It's actually ok to have dirty code (or more what you think is dirty) and not be ashamed of that, you can always refactor it later and being open source can help there too. But I must admit I'm still learning to be not ashamed .oO(... Just how many times I've seen projects where author promised open sourcing after he clean code and... nobody ever seen the author again ...)

3DzzD have interchangeable 3d renderer, for now there is 2 renderer : one for software & one for hardware (JOGL), it should be easy to create your own one by copying the existing JOGL renderer (the 3DzzDExtensionJOGL project in the devkit).

Oh I meant something different: providing more OpenGL-like API to your existing software renderer. But I didn't yet looked at your code in details (have to do other things currently) so it might also just be already there

this is old original liveconnect package from netscape, it is only used to perform java to javascript call. absolutly not requiered in most case, i needed it to compil the javascript stuff with some java compiler.

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