Q&a
(Thanks to Telamon for pointing this thread out)
* Biggest issue I have with colloda is the actual project structure itself, there no clear website just a forum, no list of supported features, whats going on in soon etc. In fact it suffers IMHO in the closed shop mentallity that OpenGL ARB has....
COLLADA has a web site:
http://khrnons.org/collada where you will find the specification, the schema, up to date presentations (the latest from SigGraph and Eurographics), some demonstration videos (including physique and FX) as well as links to PR and articles.
It also has a forum:
http://www.collada.org, where you can have all your questions answered. Also, COLLADA has now a book, which provide a guide to the specification and a lot of informations about what design principles are enforced.
http://www.amazon.com/Collada-Sailing-Digital-Content-Creation/dp/1568812876/sr=8-1/qid=1158710087/ref=pd_bbs_1/002-3971021-9680857?ie=UTF8&s=books
We can always improve the COLLADA presence on the web of course. Could you post your suggestion on the forum.
In regard to the list of supported features, I do not agree that it is not clear what COLLADA does support or does not. The specification and the book will give you that information very clearly and detailed. If you are looking for a bullet point list, you will find this in any of the latest presentations.
But I do agree that it is not clear if a given plug-in has support for a given feature. It is a good suggestion that we make this available. Note that our goal is to define a conformance test, and have products go through this conformance test, which will provide you with a feature list and quality reference for the various plug-ins.
In regards on what is 'going on soon',this information is available on the forum, for example:
https://collada.org/public_forum/viewtopic.php?t=570. Please do not hesitate to ask if you need more information.
* There is also little documentation on how something should be reflected in the Scheme.
COLLADA is one of the most documented format, with 298 pages of specification, 250 pages of book, several source code available API such as COLLADA-DOM, FCOLLADA, Whoola, all the plug-ins are available in source code, detailed presentations, and a very active forum. But I agree with you that some aspects still need more clarifications, and we are working on it. BTW, if there are aspects of the spec that are not clear to you, please let us know on the public bugzilla:
http://www.khronos.org/bugzilla, we have fixed all of the issues reported there for the 1.4.0 specification in the 1.4.1 patch release for instance.
* I currently use ODE but the ageia license on PC (free if you support hardware physics) and COLLADA integration are tempting me to have a go at that but so far I'm ODE based.
Please note that COLLADA Physics is best supported currently by Maya (with both the NIMA and COLLADA plug-in) and Blender. The 3dsMax AGEIA plug-in claims it export COLLADA documents, but instead export something that vaguelly looks like a COLLADA document.
AGEIA run-time seems to hae good support for COLLADA, including the capability to export COLLADA Physics files from the run-time, which is really good for debugging physics issues.
The Feeling Viewer
http://www.feelingsoftware.com/content/view/40/66/lang,en/ has support for physics, which is quite cool. It also support animation, shader FX, skinning, morphing..
* I can't help feel it's trying too hard to 'be everything for everyone' format, which has ended up bloating it and making it very difficult for the little guys to implement. It's a big format (500kb xsd schema, with little doc), and as I'm finding out quickly, it is difficult to implement.
The great thing about COLLADA is its design in libraries. Which means that you can create a COLLADA document that contains only physics, or only Effects, or only a visual scene and extenal reference other documents. This is actually very cool to do concurrent development on a level. You can have artists working in separate packages on their models, have a separate FX library, and use one of the tools to simply instantiate the models, assign the effects. When an artist update their model, simply update the reference.
This work really well with tools like XSI for example, where you can use 'GATOR' to take all your skinning/morphing parameters, and apply them to a new instantiated model.
It is really not that hard to implement. Here's an example of another open source physics library where the author implemented COLLADA support in a week or so:
http://www.continuousphysics.com/Bullet/
Since this is an open source project, you can look at the source code to see how this is done. Bullet als has support for run-time export of physics data in COLLADA format to help with debugging.
* The spec seems to be in a state of flux too. Maybe I've done something wrong but my the version 1.3 examples do not appear to be valid to the 1.4 spec (and I haven't found and 1.4 examples either). I might have made a mistake though. However the differences are only in minor ways - such as the asset tag, but it's still annoying.
On the contrary, the specification is really stable, and will stay stable for more than 9 months now. The 1.4.0 specification is the first standard specification, published by the Khronos group, everything prior to this is not part of the standard. There is no backward compatibility between 1.3 and 1.4, and the reason is that we needed to make major changes before it became a standard, because once it is a standard, it has to be stable, and no more changes of this nature can be done.
In regards to the samples, I agree this is very confusing since we did not post any 1.4.1 samples ! I have fixed this and now 1.4.1 samples are available, and I removed the post about the 1.3 samples. Sorry about the confusion.
* The spec allows for arrays of data, which can take any format, normals, vertices, whatnot. However, you use a seperate index list for each data stream to link it all up. This doesn't translate at all well to 3D hardware, and will require extra effort to optimizes out redundant data, producing the best ballance of stream size and stream count.
COLLADA is not targeted to be the format to use directly in the game engine, it is designed as an intermediate format for tools to communicate. Some say it is an interchange format, but it really is an intermediate format. Please read this for the details :
http://www.hexus.net/content/item.php?item=6664&page=1
This said, COLLADA *can* be used at all level of the pipeline, and it is designed so that you can take the non optimized data that come out of a DCC package (any DCC package), and process it to create another COLLADA document that contain data that is fully optimized for your application. This is quite easy to do so with the COLLADA-DOM. We actually provide a sample tool to do this: Refinery and a bunch of ready to use conditioners.
http://sourceforge.net/project/showfiles.php?group_id=157838&package_id=196258
* The p tags have no obvious documentation and don't appear to have a purpous (from what I've discovered so far).
You can see how <p> is used page 111 of the documentation, but I agree that there should be more on this element.
<p> provide the indexes for the vertex attributes that are used in a primitive (<triangle> <polygon> <line> ...)
The number of index per vertex is given by the the max offset of all the <input> of the primitive.
* Most of the ES state is also duplicated for normal openGL.
The shader FX part is the only part of COLLADA that is platform / API specific. You do not have to use this part if you are not doing anything platform specific, and use the common profile for effects. But unfortunatelly, if you want to do advanced effects, you will have to use pipeline description and shader languages that are specific to a given platform. In other workds, those definitions are exclusives, if you are targeting GL ES, you are not considering the OpenGL State.
* Furthermore, there are many, many types defined. float,float2,float3,int,int2,bool,bool2,short,uint ,listofbools,listofints,listofuints, float5,float7, float1x2,float1x3,float2x1... ETC ETC. a lot of redundancy which gets difficult to parse.
COLLADA is strongly typed. This serve a purpose, to be able to validate a document with the schema with standard tools. This is a strong point about COLLADA, and save so much time and money. The more we provide information in the schema about what data is expected, the more the standard validators can do a good job at validating the data.
It may not be the simplest thing to parse, but with the provided COLLADA-DOM and FCOLLADA source code libraries, it is a piece of cake. And if you apply the principle of doing a COLLADA->COLLADA optimization, you can even reduce the complexity of what subset of COLLADA you get at the output, and write a simple parser for your engine.
* Writing a 3dsmax exporter seems to be much simpler than a Collada->game binary tool, and probably more flexable too.
I strongly disagree with this statement, and have several real usage case that indicate the contrary. I would stongly recommand writing COLLADA conditionners, and at the last stage a COLLADA-> binary format. Not only this is simpler to do, but also work with *any* tool you may decide to use. More important, several other tools such as FXComposer can be then mix and matched in your content pipeline....
* The problem is that the Scheme has grown and grown and it isn't really precise enough in some areas. What it's really done is increased the size of my test matrix by the number of art packages I claim to support.
It is true that COLLADA is not your grand-mother simple triangle (obj) format, and have much more expresivity enable. I have seen many implementation relying on sample data, and being surprised that other tools would output something different. But if instead the implementations were done using the speicifcaion/schema, or/and rely on available API such as the COLLADA-DOM and FCOLLADA, this would not be such a problem.
But you are right that sometime the specificaion is not clear enough, and we are often surprised to find out how many ways can different people interpret the same sentence of the specification ! The COLLADA community would be obliged if you would notify on the public bugzilla what part needs to be clarified.
* That is, the Unreal engine may benefit from it, but my hole-in-the-wall engine might not.
There are so many open-source engines that are already benefiting of COLLADA. To name a few: C4 engine
http://www.terathon.com/, Unity3D
http://unity3d.com/, Ogre engine
http://www.ogre3d.org/, spineless
http://spineless.sourceforge.net/ and many others ..
