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…
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.
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?
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).
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?
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 ?
[quote]Hmm so lets pretend we are implementing javax.vecmath and make serialization compatible… err is it possible at least ?
[/quote]
Yes, it is possible. In most cases it is refactoring of KH vecmath by changing the field names, adding UIDs etc., but for some classes extra routines should be written.
Yuri
P.S. I will try to allocate time to check what is the status of Sun vecmath at the moment and if the implementor agreement (or contribution to it if it is opensourced) is possible.
Yes, it is possible. In most cases it is refactoring of KH vecmath by changing the field names, adding UIDs etc., but for some classes extra routines should be written.
Yuri
P.S. I will try to allocate time to check what is the status of Sun vecmath at the moment and if he implementor agreement (or contribution to it if it is opensourced) is possible.
[/quote]
OK-dokey.
Exacly as I thought, license states limitations on use of javax.vecmath namespace (with Kenji Hiranabe’s vecmath we fall under “Compatible Implementation” cathegory):
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…
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.
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).
[quote]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.
[/quote]
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)).
[/quote]
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”?
[/quote]
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).
Well then what is best : to introduce Kenji Hiranabe’s changes in official vecmath or to JDL his vecmath ?
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).
[/quote]
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.
