A brewing project and some arising questions...

[RitschRatsch!]

I just finished a first puplicity compliant proposal of a java project I had in mind for almost 3 years now. It's supposed to become a turn-based tactical combat game heavyly inspired by Bluebytes "Incubation" - but without the flaws ;-).
One of the issues is of course the visual apearance which I want to put more emphasis on than usually is done in GPLd game projects, since I am more of a artistic designer than a true pure rock-bottom programmer. I basically considered a design based on isometric pseudo 3D like in the classical RTS games and looked a little into JMF for that allready. I only had true 3D as a very vague maybe-consideration since all Java 3D efforts until know looked kinda outdated.
Tonight once again I feed Google with "java 3D engine" and ran into jPCT and that FSAAed bumbmapped Globe spinning in front of me.
Needles to say that jPCT looks as if it's my ticket to ride and just like what I need. Yet there are 2 issues I liked resolved before I dive into my first experiments with this awesome piece of work.

1. Heavy load performance (in terms of Java 3D)
Don't get me wrong. jPCT performs and looks better than the one or other hardcoded 3D patchwork I've got on my box. But I'd like to know if there is any expierience with mass-polygon and mass-object performance. Basically there will only be one object of aprox. 500 polygons moving at a time, since it's a turnbased game, but what happens when the screen is littered with another 150 of those standing still, including a 3D landscape, texturing, a little lighting and the one or other simple particle effect? I presume we're talking about maybe 40 000 polys at a time. Can jCPT handle that if most of them are motionless?
I've got a Athlon XP 1700+ running Linux with a sysfreq of 266 Mhz. The Globe moves at 18 FPS with all the goodies switched on, which, as I allready said, absolutely awesome. How will that be with the setting I described? Will performance break in quickly beyond a certain level? Any clue?

2. The license
As I mentioned, I want my game to be a GPL project. If I can convince the jPCT person/people that my game is not gonna be yet another dead end sourceforge corpse, is it possible that the jPCT engine could go along with it under the GPL?

Thanks in advance for any answers to these questions.

RitschRatsch!

[EgonOlsen]

First, i have to say that i remember Incubation and i also remember that i played it on an 486DX4-100 with 12MB Ram and no second level cache in software mode. That was slow...  
Anyway, back to your questions:
jPCT is a software engine which means that all geometry processing and rasterization is done by the CPU. Like all software renderers, it's fillrate limited most of the time but it also offers some optimizations to speed up geometry processing. If all of your 150 objects will be on screen at a time, the performance will be quite bad. If only a few of them are visible at a time while the others are off screen, the performance should be ok (depending on the used features and the resolution of course). jPCT culls whole objects based on their bounding boxes, so if an object's bounding box is off screen, it will be culled away very fast and not processed any further. The best way to determine if jPCT fits your performance needs, is to check it out. You may use the Primitives class to generate some "placeholder objects" (like some spheres or so) and place them into the scene in a way that roughly corresponds with what you are trying to achieve in the real game.
jPCT is JAVA and software and as such, it can't compete with a GF4/D3D hardware solution of course, but i really think that handling something like Incubation should be easily possible with it.
And regarding the license....i have to admit that don't know the GPL exactly. What is required to include jPCT into the project? I don't see a problem to include the JAR (that's what jPCT's license agreement states) but i don't want to see the sources included (which aren't publicly available anyway). I once gave the sources to some people and it got out of control, because they can never upgrade to a new version because they added their own specific stuff to jPCT which isn't included in the normal version of course. If this is ok for you, then go for it...

[RitschRatsch!]

....i have to admit that don't know the GPL exactly. What is required to include jPCT into the project? I don't see a problem to include the JAR (that's what jPCT's license agreement states) but i don't want to see the sources included (which aren't publicly available anyway). I once gave the sources to some people and it got out of control, because they can never upgrade to a new version because they added their own specific stuff to jPCT which isn't included in the normal version of course. If this is ok for you, then go for it...

The GPL is the classical Open Source License that alows usage of the source only if derative work is also published under the GPL thus preventing closed code modification and lockin after the source was published.
Once the source is released under the GPL the is no legal way someone else could lockin youre code or derative works or release it under his own license. Whereas you still could. If you haven't used GPLd code that is owned by others yourself that is.

Note that if you - for instance - release a certain iteration of jPCTs source under the GPL that copyright is still yours just as the intelectual property, of course. And that you can release jPCT under any other license you wish. It's not as some people think, that you're own code has to be OSS from thereon down!
The GPL is meant to prevent the exact problem you describe above, permitting usage of the source only if you accept copyright laws and follow the license prime issue, namely to force all derative work to be GPLd OSS aswell.

If jPCT would be included into the project I plan it would require that iteration to be release under the GPL. If you a weary about the effect of the GPL, you could restrict a GPL version to those classes actually used by the game.

Recommendation: Trolltech Inc., as many others, follow a dual license strategy with their main product, the QT library (the main widgetset of KDE). It's available under the free GPL and under a commercial license that costs money but doesn't require the products sources to be realesed as well.
This is a very good strategy, as it's great free advertisement and a benefit for those who programm in their spare time - in turn requireing them to publish their stuff under the GPL aswell; but also enables Trolltech to sell their IP whenever commercial developers are interessted but what to keep their source closed.
Since it's basically your own jPCT you could give people the option. Usually commercial sites and contract design work is 'closed' as well, and since jPCT has an emphasis on browser usage you could tell developers that sites using it that don't disclose the entire sites content, structure and code under the GPL (which they hardly would do) would require your permission or even a purchase of the commercial license.

Any further developement on the GPLd jPCT would fall back on the original product, just as the KDE libs are a great commercial for Trolltech - allthough they didn't write that derative work.

GPLing a mature project like jPCT is bound to have a major impact and gather subtacial attention amongst top software developers. Notice how the commercial Java IDE Netbeans (www.netbeans.org) took of after Suns Forte Code was released under the GPL. Since the OSS community has a top notch IDE (that is about to outrun JBuilder!) Java popularity has increased substancially, for the benefit of Sun aswell.
And still the original product is available under a commercial license along with the SunONE server package.
Expierience shows that developers are less reluctant to add work to a GPLd project than a project under the more liberal BSD license, knowing that their work won't expierience a lockin by deratives in the future (like MacOS X). Like you obviously once allready did.

To fill you in on a little more details I'll post a GPL licence here soon, so you can see for yourself.

[EgonOlsen]

Well, i'm not really happy with the GPL as i'm not really happy with the idea to release the sources. If following projects are GPLed or not doesn't matter that much to me. My point is, that i don't want to see a bunch of variants of jPCT floating around...GPLed or not...and that i can't say "hey, just update to the new version and it'll work" anymore.
Isn't it possible to enhance the license (if required) in a way that basically says: This project is released under the GPL with all the bells and whistles but this particular part of it (jPCT for example) is not and comes with its own license (which it already has), albeit it's part of the distribution/project. I don't have a single problem with jPCT being included in whatever projects, but don't like to be forced to release the sources.

[RitschRatsch!]

..and that i can't say "hey, just update to the new version and it'll work" anymore.

Well, you could release it under another name and kinda fork jPCT yourself for that purpose... :-) but I get it. It's your baby and you want to mess with it yourself and only yourself. Fair enough.

Isn't it possible to enhance the license (if required) in a way that basically says: This project is released under the GPL with all the bells and whistles but this particular part of it (jPCT for example) is not and comes with its own license (which it already has), albeit it's part of the distribution/project. I don't have a single problem with jPCT being included in whatever projects, but don't like to be forced to release the sources.

That shure is an option I'm actually considering, as jPCT is shurely a nice thing. I'd ask you to promise to release it under the GPL if you lose interest in jPCT, though. :-)
I'm gonna ponder a bit on my game idea a little more and try some stuff with jPCT and see how it works out.

[EgonOlsen]

That shure is an option I'm actually considering, as jPCT is shurely a nice thing. I'd ask you to promise to release it under the GPL if you lose interest in jPCT, though. :-)

That time is far far away in the future...
But if it ever happens that i'm losing interest in jPCT, GPLing it is an option for sure.