OK, thank you all for support, unfortunately I'll be a week off but on Saturday I'll be back on work.
By the way, now I know pretty much about how COLLADA works in general and specifically about mesh definitions and materials. The tricky part is now left : skeletal animation (also called skinning in the COLLADA doc). If anyone is willing to help me with this part, he/she is very welcomed. I thought I'd use Cal3D to do the skeletal computations. What do you think about that ? I must admit that I haven't investigated skeletal animation that much and the Cal3D thing was more of a port than a re-implementation. So either you can share your knowledge or code something (which I'll pay much attention to) or.. wait I find the appropriate materials so that I can understand all that properly and implement it.
About code availability (since that's what you're mostly waiting on), Marvin and me discussed some days ago about a universal project (hey.. one more ? yeah !) which would consist of 3D format loaders. In the end I think it could also contain better image loaders, sound (ogg/wav/mp3) and music (midi, various mod/s3m/it/xm(s)) loaders, and that in generic structures. Then every engine willing to have these features could just implement their specific part and that's it. Of course, we're not gonna reinvent the wheel when the wheel is fine : loaders which are already very good should only be wrapped (e.g. for mp3). So a new SourceForge.net will be created for all these loaders : I'm still wondering about the right name (JUL ? (Java Universal Loaders) BJL ? (Better Java Loaders) ALJ ? (Abstract Loaders for Java)). Of course, this image/sound thing is for the far future : the present is about COLLADA Loading. About integrating other formats (Cal3D/MD2/MD5/OBJ/ASE/3DS/DXF/AC/LWO/MAX) it's not excluded, and it should use the same data structures that are used currently to load COLLADA ("currently" = in the implementation I'm working on) since COLLADA is (IMHO) the most organized format of all (especially about shared copies / instance and scenes/libraries management).
About scene-oriented COLLADA files, as I said I don't see as a priority to support things like lights/cameras. I'd rather concentrate on meshes/complex materials(including shaders)/animations. Though the data structures have been designed such as you can have a "library file", eg. a file with all your game models in it and you can retrieve the ones you want (e.g colladaFile.getModel("fuzzyDonkey") ) : information about the position and orientation of these models in the original scene will also be available.
About shaders, and as I'm looking for an all-opensource solution (and as Blender doesn't support GLSL shaders directly and thus cannot export GLSL shaders to COLLADA files), maybe a COLLADA-Shaders editor (Xith3D-powered) is something to think about (Ex. questions : should the GUI be Eclipse, Netbeans, or Xith3D-based ?).
About stability, I'm almost sorry to say that I want the tools I work with to be very well designed : now it happens that I contribute to more and more of these tools (no, no, I'm not yet an Eclipse developer.. could come one day
who knows...), and that means........ that the COLLADA file loader (and the other if they're ever made) will be pretty unstable at first : and I don't exclude major changes even after it hasn't been changed for weeks. The biggest change I can foresee for now is the generalization of the COLLADA data structures used currently : they will be used for every other loaders so package and interface changes are to expect : but I prefer to having something working first.
About file sizes : in the COLLADA docs they says (ah the rats..
) that COLLADA shouldn't be used as an engine format, but just as an asset-exchange format. I don't really agree : if the scene-oriented things are left for DCC tools, COLLADA can do very well for an engine file format : and I think having the possibility to load COLLADA files from jar solves a bit of the problem.. Also maybe there are XML libs out there which are able to convert an XML to a binary one.. and still load the binary file with the same schema. All these things are to explore.
About going generic : why that ? Xith3D is great, that's a fact (and I wouldn't be contributing to it otherwise), but now itself isn't the end of the world : Marvin and I have already discussed about another engine from "almost scratch" (of course we will kindly borrow the good parts from Xith3D). So having tools independant from Xith3D is a great thing IMHO. Also, I really don't like the "scenegraph-centric" vision of some people which is really too much. A game development isn't "scenegraph-centric" it is "yourgame-centric" : which is why I want these loaders to be generic/universal/abstract/call it what you want, which is why I want XPAL to be both physic-lib-independant and scenegraph-independant, which is why OpenMali (I know, I say this word one more time and I get hanged
) is not tied to any graphic lib, which is why OneClick isn't bound to any specific library (I mean, apart from the standard Java API).
About my production rate : I've been busy in a field which isn't related to computers
So I haven't had much time but it should be back to normal in a week (see the beginning of this thread).
I think the future's bright and we have many great things to do, especially as an open-source community. I hope I have answered most of your questions, please ask if you have any left (what ? ah yeah, her name begins with a "Y" but how is that related to.. ?
).
Until the JUL/BJL/ALJ projects gets approved by SF guys the code will be available on Xith3D SVN (this is opposed to the views I expose above but hey you have to have the code somewhere, right ? It'll be soon on its own project).
So, all, see you soon on this board ! And good work while I'm off
The sun... no stress... ok I shut up
Xith3D Internals
