As you all know, COLLADA is awesome, but it’s quite intimidating to beginners. I’d like to see if it’s possible for me to write a simple document that newbies could read to get the straight facts about COLLADA so they don’t waste time (like I did) or look foolish asking the same questions over and over again (did that too).
Yes, I’ve got the Collada book and although it tries to cover all the grounds, you still have no idea where to begin once you’ve read it. Don’t even think about searching a subject by looking at the index… (hey, I’m sure Remi has corrected this in the upcoming second edition).
Here’s an outline of things that I could cover in a “Collada 101” document:
elements.
I know this is obvious for most of you guys, but it’s very counter-intuitive for newbies. In fact, I currently have to explain COLLADA to my co-workers and everyone goes cross-eyes when I mention this.
The choice of parser API
Direct parsing through Xerces, or some other XML parser.
The pros and cons of Fcollada vs COLLADA-DOM (without the politics)
Their required compiling environment. What was really tested and what wasn’t. What’s stable and what’s not.
Parsing strategy.
Basically, there are two possible approaches:
a) Parse all the libraries in memory with the proper iD, then read the scene description.
b) Read the scene description and only load things that are instanced. This is what I do, but approach (a) might be more appropriate for some.
Any others I may have forgotten?
Minimum Collada Viewer infrastructure.
When possible, it is best to have a viewer engine that is ready to receive the Collada data “as is”. I’d like to give examples of the type of piece required to get things done in the least amount of time using the STL and OpenGL.
Listing of Open-source parser example
This list could grow over time, but I feel that each group has some interesting approach which would be worthwhile to dissect. COLLADA-RT is the preffered example but come on: it’s poorly commented and full of zombie code (you know…dead code that looks alive and comes back to kill you…).
The NURBS Situation
Exactly what’s the deal with that? NURBS can be exported via ColladaMaya, but only if you buy Feeling Software’s support. It’s worth knowing about this option when you need things to work ASAP. Many Maya user rely on NURBS, so this is, like…very important. No Useless Rational B.S. please.
The indexing/de-indexeing thing
Someone at Sony sent me a pretty good explanation yesterday, so I’d like to share it (with credits, of course ).
8 ) Supporting old-style shading (like, you know…Phong + diffuse textures)
COLLADA was designed to support advanced shaders but in the process, the most simple things end up taking a lot of effort. I’d like to explain how to get directly to the stuff that is needed to display a simple Blinn and/or Phong shaded object.
=======================================
I’ll be writing this in the next few days. In the mean time, let me know if anything else should be covered. I’ll probably make tons of mistakes (my specialty), so hopefully you can correct me.
So, what gave you the most headache when you were starting. Let me know.
Hi, I have been programming with Collada for a couple of months and consider myself beginner to intermediate level.
I agree with your experience of starting software development with Collada – we really need the 101 – if not a complete book on Collada Programming. There are several blocks for the beginner Collada developer. The FCollada vs DOM issue is confusing and some clarity as to their benefits and drawbacks is required. I found FCollada to be a faster library with a relatively simple API, however, it is not fully featured. The DOM is slow, has a complex API, but is fully featured. They are both solid pieces of work coming at the problem from different directions. Both took me a long time to configure and get linked to my application.
The build environments for both libraries can be tough when you need to use Unicode and MFC in a shared DLL. You can run into a lot of STL and char/w_char linker problems. Version numbers are confusing, viewers crash, and data examples are few. Generally most of the first couple of weeks of work is spent getting known “pathways” that can load a Collada document, process it in some way, save it, and load into a viewer to assess the results. These issues are typical of an emerging technology – but it could be made much more accessible with an effective 101 guide.
Parsing methodology is a key issue, but also a basic document editing strategy is required. How do you add/remove data elements and maintain the document integrity (i.e. the internal references to the removed/added data)?
I have been using the OpenScenGraph viewer – it has a Collada loader dll and works very well with GLSL profile effects. It does not support animation – but as a basic viewer it seems very reliable and the effects work great. This viewer came to my attention via the Cg2glsl project by Heinrich Fink which in my opinion is a great piece of work. It is a good example to how to parse using the DOM and the OSG reader is good example of how to load.
COLLADA-RT does seem a bit neglected but with a day or so effort it can be cleaned up and made to be useful. Please tell us about the de-indexer thing, I think I know what it does but I would like to know what you found out.
For me the most useful thing would be a lightweight viewer loader that could be considered ‘best Collada practice’. I like your idea of an Open source parser project which can be used as a starting point for Collada developers. It should build straight out of the gate and coupled with the 101 guide it could get the novice Collada developer up and running in a couple of hours instead of days. I work on the assumption that getting more developers to use Collada quickly and easily will help the whole project.
As the lead programmer of the DOM (also the writer of the OSG DAE plugin) I have A LOT of insight into the API. The first few weeks after GDC I plan on doing a brain dump of all of my knowlege about the DOM and how to use it. It will be a lot of information and I may not have the time to format it. I may try and get some tech writer resources here at Sony to pretty it up and make it coherent (a rewrite of the DOM programming guide I have been wanting to do for a long long time). But if that is the case I will try and release the rough draft as soon as I can.
Ok, so we now have the wiki, and have already created some tutorials.
So there is some reading available, and an official place for those wanting to contribute to add content.
If you see a mistake/typo on the wiki, please go ahead and fix it.
).