Just grabbed the latest and see that Group_Base is gone...I was uncertain of its purpose but converted to using it. Now it is gone so I guess I use GroupNode?? Also many places I used Vector3f are barfing saying they expected a Tuple3f.

If possible when API/scenegraph breaking pushes are made, perhaps a quick post with what needs to be converted to make things work would be nice.

I appreciate the work that is being done...just finsihed converting things 2 days ago and now I have red X's again...YOICKS!! And then my laptop battery died...dang...I am of course hoping that is wasn't the API changes that drained my batteries...

Just grabbed the latest and see that Group_Base is gone...I was uncertain of its purpose but converted to using it. Now it is gone so I guess I use GroupNode?? Also many places I used Vector3f are barfing saying they expected a Tuple3f.

If possible when API/scenegraph breaking pushes are made, perhaps a quick post with what needs to be converted to make things work would be nice.

Sorry. I forgot to mention this change .

GroupBase -> GroupNode is correct.

Tuple3f is a super type of Vector3f so you can easily proceed using Vector3f and everything should be fine. Or am I misunderstanding you? Please quote the method call.

Marvin

Edit: but it should nearly never be necessary to use GroupNode. What you you using it for?

Trying to remember, I guess the BranchGroup is a Group API was changed recently (yes I saw the posts). When reading OBJ's I was adding them to Branchgroups but using Group as a receiving variable...something like that, so I dropped down to GroupBase instead. Cannot remember exactly and can't reference my code right now.

Trying to remember, I guess the BranchGroup is a Group API was changed recently (yes I saw the posts). When reading OBJ's I was adding them to Branchgroups but using Group as a receiving variable...something like that, so I dropped down to GroupBase instead. Cannot remember exactly and can't reference my code right now.

When you're loading models, you'll certainly want to move / rotate / scale them. So you won't want to add them to a BranchGroup, since BranchGroup is only allowed to be used as very root group in the scenegraph (due to recent changes). So using Group as receiving variable is ok.

btw. I've created a new Loader base in org.xith3d.loaders.base, which I would like to see as the new base for all loaders instead of org.xith3d.loaders.scene. The Scene and Model classes in this new package extend BranchGroup respectively TransformGroup, which is quite handy to put them into your scene (or make them be the scene in case of a whole loaded scene).

Sounds good...I got in the habit of adding stuff to BG's and then adding BG's to TG's..which is pretty stupid on my part. One of the reason I reanimated the scene tree graph J3DTree was to find and reduce the empty/redundent groups I was creating. I will look at your suggestion.

Take care of Sun license/copyright for javax.vecmath - I was mentioning this time (a year or so) ago on this forum, and it was the stopper for me to publish it.

I believe we (you) shall get explicit permit of Sun to create a sofrceforge project for vecmath... or maybe I am wrong...

I don't know, why we should be forced to get the permission of Sun. It is a complete rewritten and different code. It's only based on the vecmath interface. And I don't believe an interface can be protected by a license. And we don't need to write on the project's page, that the lib is compatible to Sun's vecmath (even if it is). So it is just a piece of software, that Sun doesn't have to do anything with. Do you agree?

D. Java Technology Restrictions. You may not create, modify, or changethe behavior of, or authorize your licensees to create, modify, orchange the behavior of, classes, interfaces, or subpackages that arein any way identified as "java", "javax", "sun" or similar conventionas specified by Sun in any naming convention designation.

This is from Sun BCL, and similar statements exist (were existing when I checked that - read: a year ago) in other licenses.

I prefer to have a permit... You know, I am also contributor of JOGL and I have an agreement signed with Sun...

Anyway, Kenji Hiranabe vecmath is NOT 100% compatible with Sun Vecmath, so we can not pretend we are implementing javax.vecmath APIs (at least, serialization is not compatible).

This is anyway very tricky aspect (I mean copyright law and all these licenses).

D. Java Technology Restrictions. You may not create, modify, or changethe behavior of, or authorize your licensees to create, modify, orchange the behavior of, classes, interfaces, or subpackages that arein any way identified as "java", "javax", "sun" or similar conventionas specified by Sun in any naming convention designation.

This is from Sun BCL, and similar statements exist (were existing when I checked that - read: a year ago) in other licenses.

I prefer to have a permit... You know, I am also contributor of JOGL and I have an agreement signed with Sun...

Anyway, Kenji Hiranabe vecmath is NOT 100% compatible with Sun Vecmath, so we can not pretend we are implementing javax.vecmath APIs (at least, serialization is not compatible).

This is anyway very tricky aspect (I mean copyright law and all these licenses).

Yuri

Ah. Good to know. Maybe we should consider changind the package names.

You sayd, you're a JOGL contributor. Some days ago croft sayd, that JSR-321 is released. Can you say, if there're any performance boosts in the new release compared to the one, we're corrently using?

I prefer to have a permit... You know, I am also contributor of JOGL and I have an agreement signed with Sun...Anyway, Kenji Hiranabe vecmath is NOT 100% compatible with Sun Vecmath, so we can not pretend we are implementing javax.vecmath APIs (at least, serialization is not compatible).

Hmm so lets pretend we are implementing javax.vecmath and make serialization compatible... err is it possible at least ? If it's in an SVN repository I don't mind working on it..About the agreement, how can you obtain one ? Do you plan to do so ?

Exacly as I thought, license states limitations on use of javax.vecmath namespace (with Kenji Hiranabe's vecmath we fall under "Compatible Implementation" cathegory):

Quote

3.1.3 A Compatible Implementation may not modify the functional behavior of the "Java Classes" which means the specific class libraries associated with the Technology; and3.1.4 A Compatible Implementation may not modify, subset, superset or otherwise extend the Licensor Name Space, nor include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required and/or authorized by the Specification. "Licensor Name Space" means the public class or interface declarations whose names begin with "java", "javax", "com.sun" or their equivalents in any subsequent naming convention adopted by Sun through the Java Community Process, or any recognized successors or replacements thereof.

So if we want to have better vecmath OFFICIALLY, we have two options: 1) to contribute changes directy to vecmath CVS (which will need Developer CVS access on vecmath, and, therefore, contributor agreement, similar to one I have for JOGL), or 2) execute JDL with Sun (I think I can do this on behalf of Xith3D Project Group), create compatible implementation, ensure it passes TCK, and distribute it under terms of JDL (then we have to manage JDL agrements with our users).

I believe 1) is more appropriate but on the other hand will be more complicated. As a companion to 2) we may suggest vecmath group to take the changes after we have them passing TCK. But, anyway, to get TCK, we have to execute JDL.

...that's the world of laws and licenses... ...and we also have to deal with this...

So if we want to have better vecmath OFFICIALLY, we have two options: 1) to contribute changecs directy to vecmath CVS (which will need Developer CVS access on vecmath, and, therefore, contributor agreement, similar to one I have for JOGL), or

This approach has a big flaw : vecmath is meant to be used in single or multi-threaded environments, while we don't need multi-threading *at all*. In order to be thread-safe. Sun's vecmath generates lots of garbage (e.g. 3x3 or 4x4 raw matrices are created with some get() method calls... this is just astonishing ! putting those sames matrices as members take little more memory and generates nearly no garbage (some allocations are unavoidable)). So I don't think Sun's vecmath really goes well with our needs/goals.

2) execute JDL with Sun (I think I can do this on behalf of Xith3D Project Group), create compatible implementation, ensure it passes TCK, and distribute it under terms of JDL (then we have to manage JDL agrements with our users).

Well why not if it's the only solution to do that legally. What exactly do you mean by "manage JDL agreements with our users" ? Be it Sun's vecmath JDL-ed lib or Kenji Hiranabe's vecmath JDL-ed I don't see the difference for users (about licenses).

This approach has a big flaw : vecmath is meant to be used in single or multi-threaded environments, while we don't need multi-threading *at all*. In order to be thread-safe.

Can you please point me to this highlight in the specification? Anyway, this statement does not imply any method to be synchronized (what we are trying to avoid by being "non-multithreaded"), it just assumes that concurrent method calls are thread-safe.

I just checked the Sun vecmath source, and did not find ANY "synchronized" keyword.

Even first-look at Sun vecmath show it is not thread-safe: check Color3f.set(Color) and Color3f.get() - get may return completely wrong color if set(...) is called from another thread concurrently.

So I don't see it as an issue at all.

Quote

putting those sames matrices as members take little more memory and generates nearly no garbage (some allocations are unavoidable)).

If you take a closer look to Kenji Hiranabe's vecmath, you will see that he does not use arrays at all - search for "new" allocation operator and you will be surprized bu ABSENCE of new arrays! He is using parameter passing (i.e. local variables) instead of arrays, and this voids need to make shared matrices, so does not compromize thread safety at all.

Quote

What exactly do you mean by "manage JDL agreements with our users"?

If we distribute vecmath under JDL agreement (as required by Sun JDL), we have to ensure that all of our users ("third parties") accepted the terms, and better in written form (as required by Sun for their JDL). Aletrnative is BCL (Binary Code License).

If we distribute vecmath under JDL agreement (as required by Sun JDL), we have to ensure that all of our users ("third parties") accepted the terms, and better in written form (as required by Sun for their JDL). Aletrnative is BCL (Binary Code License).

But currently users have to download vecmath separately but I never reviewed whatever about vecmath license.. it was there, I just used it (I know this is counter-professional).. only enterprises will mind.. but ok I got it.

I'm not very happy with the rocks Sun puts into developer's ways. I think it would be best to change the package names from javax.vecmath to something like org.linalg or so. Then we would be free to choose a license like BSDish and change the API's behaviour if needed.

I don't see it is too much problematic... I think that we can even [theoretically] try to push Sun to relax vecmath license to BSD (as it happened with JOGL - it is also project managed by Sun and it is under BSD!)...

I think before making any decisions we should try to speak to Sun people and get their opinion, if possible.

I don't see it is too much problematic... I think that we can even [theoretically] try to push Sun to relax vecmath license to BSD (as it happened with JOGL - it is also project managed by Sun and it is under BSD!)...

I think before making any decisions we should try to speak to Sun people and get their opinion, if possible.

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