I was thinking about the third-party libraries earlier and realised that we really havn't credited the authors and have possibly voilated their copyright (most licenses require you to list the distributions terms etc...).

I think we should have (in the xith3d cvs tree) a readme text file in the third-pary folder that listed all of the third party libraries along with, their versions, copyright holders and main download location or other contact details. Also, we probably should have a copy of their respective licenses in each folder.

While this is not a huge issue now, probably a good one to get out of the way.

Is all of the code BSD-licensed? The vorbis library for example? Someone writing a closed-source (or simply non-GPL) application will have to be carefull if using a feature of Xith which uses GPL code (ie they will have to not use that feature). More importantly the vecmath library being so intergral - I guess the one is the Sun one? Has anyone tried this one: http://objectclub.esm.co.jp/vecmath/? If that latter is reliable it's probably good to switch to that... Sun have a rather energetic legal team after all

Normally it would be the developer of a program that would worry about such matters (eg in the case of Java, how to distribute the JRE) but in this case, we are distributing the libraries along side Xith3D rather than telling people where to get them and because of that we should make the legal stuff very clear (ie. tell people what the deal is and make sure they know they should check it all out themselves).

2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you:

(i) distribute the Software complete and unmodified and only bundled as part of your Programs,

(ii) do not distribute additional software intended to replace any component(s) of the Software,

(iii) do not remove or alter any proprietary legends or notices contained in the Software,

(iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and

(v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.

thanks for the library, I might plug that in and give it a spin with Xith3D tonight, see if it behaves itself

To summerise the Third-Party library issues:* the Java3D native dep is gone,* and it looks like Java3D vecmath dep is on the way out* once the xith_utilities future is clarified, we will be good to go.

When people start distributing their projects, the distribution issue will be extreemly important, so I think it is wise to resolve it early. I shall conduct some tests with the vecmath against the example code I have and aganst the official demos (com.xith3d.test).

I'm sorry I misunderstand your last post.Did you give a whirl?It read like you modded your post.Anyway, please let me know you success/failure as it goes. The APIs is very incomplete compared to J3D VecMath, but it's building out as needed and we didn't need anymore other than the invert()s.I think your tests will be far greater than ours so you guys will hit errors/weaknesses before I.I will fix ASAP, of course, anyone can now and I'll fold (or you guys can) it back into the "offical" release.

It would be a lot better if the package had the same name as the official one (my reasons for this are in the other thread). Fair enough it's not too hard to change a few import statements with a batch find-replace but i feel even that I should not need to do

I would not think it would have the same package name. If we made this switch it would by ripping sun's vecmath out completely and refactoring for the new library. It would not matter what the package name was. Of more importance would be the compatibility on method signatures and its behavior.

Fair enough, not too hard to change the Xith3D code, and it will be good to be totally rid of Java3D.

Would this however add another hurdle for people porting Java3D code to Xith3D? Would it matter if it did?

Has anyone actually tried using the other javax.vecmath implementation with Xith3D maybe all we will have to do is just replace the Java3D one with that and all our (copyright) problems will be solved? I shall be testing it myself today.

An enhanced vecmath seems like a good way to go. Is full backward compatibility to the old vecmath library (eg. the colour types) somthing we need as well?

One question I would really like to have answered is what can we do about xith_utilities.jar? I understand that the code is currently David's. Are there any plans to either open source that library or integrate the nessesary components into Xith3D? Either way it would be nice to be able to tinker with the code directally and it seems unnessesary that Xith3D would use a closed source library like that one when the rest of the project and it's related libraries are totally open source.

xith_utilities.jar has been integrated in the Xith3D core, which solved the license problem.

Thanks, that's fine.However what's with vecmath? I've read here that it's the Java3d's vecmath so ... in case you would like to distribute a game based on Xith3d: would you really have to include the entire Java3d package, too?

I'm currently using Kenji Hiranabe vecmath with few modifications for xith3d. vecmath.jar included by default in xith3d is one used in java3d and it generates not really needed garbage in some of methods. Only problem with Kenji classes is lack of TexCoord4f, but it is trivial to add.

If you are interested, I can prepare corrected version of Kenji classes and post for inclusion into xith3d.

Xith3D currently uses the J3D vecmath.jar, I belive that Kenji's would be the best replacement. abies modifications have my +1

All third party libraries will need a copyright attribution and license like for all software and log4j is no different. Look at the JRE or SDK - there is a file named "THIRDPARTYLICENSEREADME.txt" which lists all third party code Sun uses and the respective licenses. You can license your code however you like - but you'd have to respect copyright of the libraries too. Even if it's the case that all your third party libraries and code is the same license eg. BSD - you still need to include seperate licenses as each is copyright by a different author. It's just like writing an essay - you have to include a bibliography.

However, I am not a lawyer, that is merely what i have observed others do.

I vote +1 for testing an alternative vecmath API. I'd like to see a library which is maintained (or at least author can be reached by e-mail), so you can optimize it or add missing functions if necessary. Don't know if that's the case with Kenji's API, but hope so.

Compared to Kenji version, I have added explicit row/column major accessors for matrices (but I have left original ones in place), removed one unneeded allocation during matrix multiplication and added TexCoord4f/4d.

If you have anything against row/column accessors, it is trivial to remove them - I'm not particulary attached to them since I have discovered transpose matrix opengl extension - but they might come useful at some point in future, when interfacing to some math code.

I just reviewed and tested Kenji version of vecmath modified by Artur Biesiadowski and only I can say - this is good and compatible with Xith3D engine.

I was able to compile engine and the apps based on it without any problems.

BTW, to make it running with my apps I had to add explicit declarations of serialVersionUID to all the serializable classes [except of GMatrix, GVector (incompatible!) and TexCoord4d] to make it really working. Also one incompatibility is that some objects do not implement Cloneable, and one may encounter Java3D->Xith3D porting problems because of that.

So, my suggestion is to switch at least to this library because of it is open source. And, of course, spend some short time to make it compatible in serialization [99% done] and cloneability [todo].

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