Can we leave it at “lots of people don’t use OS who would like to, exept that the licenses are too scary”?. If you’re EA, and have a battalion of lawyers, no problem. If you’re a development studio, you may or may not be prepared to risk working with a license that is less than 100% clear.
Yes indeed…
…And if you’re an independent developer you don’t have the
luxury of a battalion of lawyers to interpret the license for you…
Actually, even a single lawyer would be extravagant I guess
Well David, I have a question for you. Are you planning on leading the charge, or are you just here to bitch? It seems to me that what everyone would really like is some kind of high level scenegraph API similar to Java3D that could sit on top of JOGL, LWJGL, or better yet, both. Further more, we’d like it to be layered such that a developer could decide how much or little of it to be used for his own project.
If there’s one thing I’ve learned from LWJGL, it’s that sitting on your hands waiting for Sun to implement features you want gets you one thing: warm hands. How long was LWJGL around before Sun finally got around to making JOGL? And now that they have, which is the better API? (Don’t answer that last one, I don’t want another thread devoted to that!)
My point is, if you just suck it up and rework your engine to run on top of JOGL or LWJGL, you’ve spent a couple months to make your game work again, and done exactly what you’re arguing against. What happens when you’ve moved on to your next game? Are you not stuck writing yet another scene graph?
What we need is someone to lead the charge and start up an opensource project to make this nice, generic, universal scene graph API for all of us to use. Then the rest of us need to get off our laurels and help it grow. And if all this happens, we can finally sit back and enjoy the fruits of our labor, and never have to write another scene graph again.
I know, ultimately, that this post is horribly hypocritical. Who am I to ask others to lead a charge I’m not willing to lead myself? But maybe it’s not quite that bad. I’m certainly willing to jump in and do my part if someone starts such a project. Perhaps first I can test the waters and see how many “hell yeahs” I can get.
Paul
Hell yeah!
I don’t have the personal bandwidth to lead the charge, but I will certainly contribute whatever I can to an OS Java3D scenegraph implementation, if-and-when one is started.
In the meantime I am going to keep using Java3D as-is, because it is (mostly) good enough for our game right now.
–Brad
Hmm, it seems perhaps I should’ve read all the replies to David’s post before writing my own. It seems I may be simply reiterating the same sentiment that this thread is already rife with. Everyone’s willing to contribute, but nobody wants to be in charge. Sounds like a typical open source endeavor.
Paul
I’m “in charge” of our stuff I just say Yes to most things.
Cas
[quote]Everyone’s willing to contribute, but nobody wants to be in charge. Sounds like a typical open source endeavor.
[/quote]
Lucky you !!! My experience with open source projects was that everybody wanted to be in charge and no people actually contributed any useful code
Not always, but often enough…
Yes, what I’m referring to are all the projects that never even get started. The ones where everyone is willing to put in a little time implementing some small details, but nobody wants to do the high level design and administration. If somebody were to set up some space in sourceforge and check in a nice fat design spec, I bet the code would start to fill in pretty quick.
Well, at least I wouldn’t mind taking a stab at some bits here and there.
Paul
Well, I guess I can say that my group of developers, Full Sail fellows as well as a couple outside, are in the process of writing a Java3D compatible scene graph targeted for gaming and that will be open source. We are planning to use it for examples of how to make one and why and for content import in a Java game programming book we are working on for Charles River Media that is due out at next GDC.
Unfortunately, we have expertise to set up and maintain a real public modifible and accessible repository, a’ la JLWGL.
Our path is non-renderer specific, that is independant of the render engine, so our example JOGL renderer could be replaced or ported to JLWGL as well, but our main goal is to be able to use exist J3D loaders with little or no changes to them - which may ultimately involve conversion utils for loaders that won’t link to our classes…
When we have a 0.1 release we will examine our options again.
In any case, we will be happy to release what we can and perhaps even intergrate into another project should another public project pop up in the meantime.
If you are working on similar stuff or are interested, I suppose we should all speak up so we can at least exchange ideas, and perhaps even share in actually forming a standard spec.
Shawn -
Glad to hear from you. I was hoping to provoke responses like yours. I was also hoping Alban from OpenMind would chime in as well, but nothing so far. David’s posted something over at puppygames.net intimating that he’s working on something that will ultimately be freely distributable, so I would have also liked to hear from him.
It sounds like everyone who really knows what to do is off doing it by themselves. Unfortunately this leaves people like me unable to pitch in until after the various libs are done, at which point it’s probably moot anyway.
Sigh.
Paul
[quote] […] our main goal is to be able to use exist J3D loaders with little or no changes to them - which may ultimately involve conversion utils for loaders that won’t link to our classes…
[…]
[/quote]
Do you have any specific loaders in mind ?
Compatibility with existing java3d loader will come at great price, if you want to be really compatible.
If we are talking about geometry+material-only loaders, then it is not worth it. Writing such loader takes few days and it is a lot easier to recreate it for any particular scenegraph, then to go in hoops to make your SG compatible with java3d line-for-line.
On the other hand, if we are talking about a bit less trivial loaders, I don’t think you have any chances of being compatible without emulating entire java3d. For example, for my NWN loader, you would have to emulate behavior sheduling (for animations and emitters), entire viewplatform/view/canvas/world hierarchy (for particles), and most of texture handling/modes. Plus scenegraph cloning and io, at least proxies. A lot of work. A lot more that it would take me to rewrite this loader on top of any reasonable scenegraph, especially if it would be more open than java3d.
Please rethink this route. Make a list of all loaders out there which you really want to use. Check which of them will never work without full java3d support (xj3d is one of them I suppose and only one really worth the effort, I’m afraid). And then look again on this shorter list and ask if your effort in staying java3d compatible is going to pay off.
Unless you are aiming at creating full java3d clone at some point. In such case, in addition to supporting loaders, you would support all applications out there - and this is certainly something which would be A Good Thing™. But again, do you really want to do it ?
I can think of several off the top of my head that we have gobs of content for.
Our OpenFLT laoder, a terrain system loader we have, our character graph and animation loader, and a .x loader we made for testing.
Also, I woudl like to write one for ACE a 3DMax ASCII format, etc. etc.
None of our loaders have ever use Java3D behavior objects with the exception of LODs which our graph could still hold and mark as a LOD node but with no running behavior.
Our original engine work from the begining with J3D avoided using there behavior, collision and sound stuff. That is it only used the graph for common data storage ( and many times just as intermediate format from other loaders) and the renderer.
Many groups have written loaders and not release them to the public, but could still get there data and more easily port what they have to the JOGL world, if the graph is compatible.
There are ALLOT of projects out there that fit this model, with ALLOT of content already there and more on the way.
We feel that content is critical, and wish to support that as best we can.
(BTW this message was posted from Konqueror running on a CD booted Knoppix Linux “install” - it worked great! )
Well Paul, I don’t have the time to write a nice generic meet-all-needs scenegraph and renderer. Of I will attempt to keep it as generic as possible and reusable as possible and hopefully it can be useful for other people, either as an example or maybe even to be used. But personally i dont feel qualified to design a perfectly modular, portable, efficient scene renderer. Maybe by the time we are done with Magicosm I will feel qualified. But my first responsibility is to my project our of respect for the many people who have worked for 3-4 years on it.
I am writing this so that the lowest level can be JOGL, LWJGL or whatever API. But I am starting with LWGL for now since it is mature and fast and has repsonsive devs.
All the stuff in this effort will be under the name Xith3D and will be stamped with a basic Apache like license granting full usage rights to anyone for any purpose.
It will support scene graph, shadow volumes, collision detection/prediction/prevention, fov culling, occlusion culling, etc.
Assuming it works well I will open up a source forge project and let you all have at it. I have the basic scene graph, fov culling, spatial trees, plus all the geometry containers finished and am working on the first pass at the rendering, borrowing heavily from the lwjgl_sg code posted here. I did make a decision to use the vecmath library because I think it is well written,but there are free 3rd party ports if that becomes a legal issue.
I still say the most interesting stuff is higher level, stuff like particle systems, sky dome, water, terrain, animation, loaders, vegetation, etc which is the core of gaming engines.
Don’t know if it will be of any help but the code talked about in this thread http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1049466445;start=45#45 is up for grabs. Work still has me too busy to continue work on it.
[quote]Okay well it is slow and many pieces are still missing, for instance lighting doesn’t work yet but here it is, call it alpha 1 of LWJGL-SG.
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_api.zip - The javadocs, such as they are
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_src.zip - The source code
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_bin.zip - Everything you need to run the examples
[EDIT]
I run on Win2K so if you use LWJGL on Linux replace the library file in the lib directory.
[/quote]
Hey z! Yes That code was a huge help. The basic java3d node structure you did saved me a week at least and your SimpleRenderer class is a great starting point for me to experiment with. I decided to use the vecmath library instead of the lwjgl.vector package through.
David -
Yes, perhaps what you’re suggesting is the best route. I fully understant not having the time to try and write something truly generic and portable. I’d be shocked and horrified if you didn’t say “Magicosm comes first.”
It sounds like the part you’re starting with is exactly the part I would be totally lost on (culling, lighting, etc.) If you post this when done (which it sounds like you will), I could see refactoring it to be a nice, tight, generic lib. I had originally thought this kind of layered structuring would need to happen first, but I can see how one could start with something that just works and then try abstracting it.
And of course, I agree with you that it’s the higher level stuff that’s really interesting (animation, terrain, etc.) I guess I will just have to shut up, sit down, and wait to see what your scenegraph looks like when it’s done.
I will try to be patient.
Paul
[quote]Hey z! Yes That code was a huge help. The basic java3d node structure you did saved me a week at least and your SimpleRenderer class is a great starting point for me to experiment with. I decided to use the vecmath library instead of the lwjgl.vector package through.
[/quote]
Excellent, glad someone is getting some use out of it.
DISCLAIMER: I am not a lawyer, and I am not qualified to give legal advice.
[quote]DISCLAIMER: I am not a lawyer, and I am not qualified to give legal advice.
I agree with oNyx.
You quoted paragraph two of section five. Here’s paragraph one and two:
[quote]5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a “work that uses the Library” with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a “work that uses the library”. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
[/quote]
It seems crystal clear to me that paragraph 1 is referring to dynamic linking, such as linking to a jar file, and paragraph 2 is referring to static linking.
[/quote]
Ok, it seemed crystal clear to me. Turns out I was wrong. According to the Free Software Foundation’s Dave Turner (the man behind licensing fsf.org), “This sort of linking falls under section 6 of the LGPL.”
Here’s a quote from section 6:
[quote]6. As an exception to the Sections above, you may also combine or link a “work that uses the Library” with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable “work that uses the Library”, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user’s computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
[/quote]
Here’s some linkage to discussions on this issue:
http://linuxintegrators.com/hl30/blog/technology/?permalink=LGPL+in+Java.html
http://article.gmane.org/gmane.comp.jakarta.poi.devel/5900
And here’s a link to the LGPL itself:
http://www.gnu.org/copyleft/lesser.html
I think the main conclusion is that the license is a complete mess, and with the right/wrong weasels (er… lawyers) and people making trouble it can lead to problems.
Note also that as far as I am aware the LGPL (as most other ‘open source’ licenses) has not yet had the opportunity to prove itself in a court of law… it’s never been “tested”
I would feel safer using something that is a bit easier to understand.