[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:27575"]
Please give me the URL of the existing website/SVN repo. I’m willing to take a look at it. I’ve always been for joining forces, whatever people said.
[/quote]
I sent you a pm, please let me know when you had time to take a look at it 
Yes, this is what I find so laughable. In spite of responses that show that jME is superior to Xith in every way you “found Xith3D more at my convenience”. Well, good luck with that. :
[/quote]
Thanks. You too.
If you’d take a look at the current state of the community(s), regarding current code, current usage of that code, licensing, etc. if you want jME to switch to your unified math library, the only solution would be to take jME’s math code and work from there. That, if you did look into all these things… would be the only reasonble thing you can expect from us, as any reasonable person would conclude.
Maybe something like that is true for Xith too, I dunno, I’m no Xith expert… I know enough from using it briefly there’s too much I don’t like about it, but -and please pay attention to this- I’m only saying this to illustrate that this absolutly does not change one damned bit, since I’m not a Xith developer or even user, and thus it’s none of my buisness.
If Xith doesn’t feel like switching either, for whatever reason, you have a problem. That doesn’t mean you can’t make your grand unified math library… as long as you believe you have the skill, dedication and tact to make one so good we’d be stupid not to use it. You just can’t reasonably expect that we believe that. Not even after Integer.MAX_VALUE forum posts on the subject. Good code however, can be very convincing…
I think the last part of your post is really ironical but I don’t understand what you mean by the Integer.MAX_VALUE forum posts ?? And no I don’t believe that I have the skill nor tact nor knowledge to make one so good […] if that was the case I wouldn’t need java.net
@sunsett : to be fair I’ll have to give jME a serious try.
I’m sorry I shouldn’t have been edgy about that coding habits.
I think the fact I am/was a “very biased Xith3D developer” was due to the fact I spent quite some time for Xith3D and so I feel engaged in it so I have some difficulty to accept some APIs may be better suited. But now I see clearly APIs are evoluting and sometimes die to be replaced by better alternatives… And it’s risky to bet on a single API.
Took me a while before I decided to do this post.
jME seems nice after all, and as my FPS seems pretty low in my Xith game, and Xith3D -> jME transition (+learning) seems to take not much time I decided to port my game to jME to see the difference.
However I’m willing to continue to support both libs… Oh and BTW I changed the logos they’re 40-pixels wide instead of 50 and I put one about jME so users can try by themselves (Does Java3D have a logo ? ;D ;D )
Offtopic:
About the logos… everybody on this forum knows what Xith and jME are and where to find them. we don’t need links
Further, they are still hideously large, even at this size. But that’s not the point really, they have no purpose for this audience.
OK, second person to complain I removed them.
[quote="<MagicSpark.org [ BlueSky ]>,post:24,topic:27575"]
If Xith doesn’t feel like switching either, for whatever reason, you have a problem. That doesn’t mean you can’t make your grand unified math library… as long as you believe you have the skill, dedication and tact to make one so good we’d be stupid not to use it. You just can’t reasonably expect that we believe that. Not even after Integer.MAX_VALUE forum posts on the subject. Good code however, can be very convincing…
[/quote]
I think the last part of your post is really ironical but I don’t understand what you mean by the Integer.MAX_VALUE forum posts ?? And no I don’t believe that I have the skill nor tact nor knowledge to make one so good […] if that was the case I wouldn’t need java.net
It’s not ironic. It’s the truth… I’m trying to explain to you that making forum posts about how library X and library Y should be unified won’t make that happen. Not even if you repeat it many times.
It’s a noble endavour, and I can see the benefits of a good unified math library… but until you make one that takes reality into account -that there’s at least one (again, can’t speak for Xith) well established engine out there that already has a good math library- you can’t expect people to adopt your ideas, or expect them not to be skeptical.
In practise, I think it’s not easy to write a good maths library (read: one better than what we have now) because you want to unify other programs. I’d have higher hopes for someone who has a big passion for maths and wants to make a very functional and fast math library. If you think you’re that last person (or both, I guess) I wouldn’t want to discourage you… a good library can hold it’s own, regardess of wether jME or Xith wants to adopt it. But if you plan to just put together some existing functions and break the syntax in the process, I don’t think it’ll gain a lot of traction.
Yup a good math library needs to have quality. Even if it isn’t as fast as other libraries fine-tuned to a certain engine it must at least provide other benefits that a math library specific to a certain engine doesn’t have. It certainly helps discussing the differences and the benefits each math library offers since it’s rare for engine developers to document this important info anywhere.
Another subject that would be interesting to discuss for unification would be content loaders for 3d scenes. Each engine usualy has half a douzen of specific content loaders which do exactly the some thing when parsing content. Wouldn’t it be easier if we worked together to create a unified library for content loaders? At least the content parsing part would be the same for every engine and the model used to represent the parsed content in memory could be a sort of “dom” model. Leaving only the code to translate from the “dom” representation of the content to each specific engine.
There is a lot more things that can be unified for the benefit of all.
I think the last part of your post is really ironical but I don’t understand what you mean by the Integer.MAX_VALUE forum posts ?? And no I don’t believe that I have the skill nor tact nor knowledge to make one so good […] if that was the case I wouldn’t need java.net
It’s not ironic. It’s the truth… I’m trying to explain to you that making forum posts about how library X and library Y should be unified won’t make that happen. Not even if you repeat it many times.
It’s a noble endavour, and I can see the benefits of a good unified math library… but until you make one that takes reality into account -that there’s at least one (again, can’t speak for Xith) well established engine out there that already has a good math library- you can’t expect people to adopt your ideas, or expect them not to be skeptical.
In practise, I think it’s not easy to write a good maths library (read: one better than what we have now) because you want to unify other programs. I’d have higher hopes for someone who has a big passion for maths and wants to make a very functional and fast math library. If you think you’re that last person (or both, I guess) I wouldn’t want to discourage you… a good library can hold it’s own, regardess of wether jME or Xith wants to adopt it. But if you plan to just put together some existing functions and break the syntax in the process, I don’t think it’ll gain a lot of traction.
[/quote]
I understand and I agree.
If you are motivated I may dedicate some time : I think it’s useful.
BUT do you know the Xith Collada Converter that Croft did ? If you implement COLLADA, you add support for 3DS, OBJ and MD2 by the mean of the COLLADA Converter… I think it should be made independent from Xith…
That may be a good idea. Being xml based it should not be too hard to make it scenegraph independent.
I heard some guys saying the XML is way to heavyweight and slow to load… Well we could zip it easily… For loading speed it’s another thing.
Did they provide any benchmark or demo? Slow compared to what other scene format? Without a benchmark what they say isn’t very useful.
Ahm right sorry I can’t remember wether it was DarkProphet talking about Volatile Engine or a talk about jME… I’ll dig into it. What I remember is it was compared to a custom binary file format.
But anyway I think XML is the way to go and as COLLADA is designed to be a standard (and has assets to become so) then I think we should use it if it hasn’t really big problems about loading speed.
[quote="<MagicSpark.org [ BlueSky ]>,post:33,topic:27575"]
I heard some guys saying the XML is way to heavyweight and slow to load… Well we could zip it easily… For loading speed it’s another thing.
[/quote]
Of course XML loading is slower than a binary and I don’t understand, why geometry data isn’t swapped to a binary file, while the diescription about their layout and size (postions, normals, tex-coords,…) and other things is sotred in an xml-based format. Such a hybrid format has both advantages.
However, COLLADA has other other reasons, which prevent a fast loading. The main is definitely that the vertex-elements/attrubites (positions,normals,tex-coords) all may have separate indices. OpenGL (and D3D) do ony support a single index. Now, note that the convertion process is O(n^2), which makes COLLADA unsuitable for fast loading resources at runtime.
For those how are interested, I wrote an article which mentions those points a bit more deep I guess: Creating Three-Dimensional Animated Characters: An Experience Report and Recommendations of Good Practice
Don’t get me wrong, COLLADA is a great format, but its main propose is interchangability between digital contant creation tools (3dsmax, maya, xsi, blender,…). It also helps that people don’t need to write hundreds of exporters, since COLLADA support is available for most. My recommendation would be: write a abstract collda converter framework.
Of course XML loading is slower than a binary and I don’t understand, why geometry data isn’t swapped to a binary file, while the diescription about their layout and size (postions, normals, tex-coords,…) and other things is sotred in an xml-based format. Such a hybrid format has both advantages.
However, COLLADA has other other reasons, which prevent a fast loading. The main is definitely that the vertex-elements/attrubites (positions,normals,tex-coords) all may have separate indices. OpenGL (and D3D) do ony support a single index. Now, note that the convertion process is O(n^2), which makes COLLADA unsuitable for fast loading resources at runtime.
For those how are interested, I wrote an article which mentions those points a bit more deep I guess: Creating Three-Dimensional Animated Characters: An Experience Report and Recommendations of Good Practice
Don’t get me wrong, COLLADA is a great format, but its main propose is interchangability between digital contant creation tools (3dsmax, maya, xsi, blender,…). It also helps that people don’t need to write hundreds of exporters, since COLLADA support is available for most. My recommendation would be: write a abstract collda converter framework.
[/quote]
Please explain further : detail your idea.
The first part would be a collection of classes which parse a .DAE - collada file and allow to access the data through objects (mesh,…). It would try to use float arrays and nio buffer only for geomeytic data.
One possibe approach would be to use jaxb to autogenerate them. AFAIK, Croft did this?! The problem is that the generated interface is usually pretty ugly: it uses java.util.Lists instead of arrays and therefore java.lang.Float instead of float, further list contain multiple types which have to be tested with intanceof, etc. I don’t have much experience with jaxb, but maybe the generation can be optimized by better configuration files.
From that on, it should be possible to save the data easily into other formats - of course additional helper classes could be usefull. IIRC, there are ongoing efforts for such an approach. I hope such libraries are idependent of math or rendering libs, so they can used widely…
Would you commit time to go toward this goal ? You may contribute to Croft code…
Well, there is no hurry for myself, as I have written exporters for 3dsmax and Maya for the format I use. However, I think in order to support more DCC-Tools, a COLLADA converter would be the best. So, if Croft would like to, why not…