   Collada in the asset pipeline
  I've been tinkering with the ColladaDOM recently, investigating whether or not I'm going to use Collada as part of my asset pipeline.  I like the concept and the fact that it's been adopted by the big players such as Autodesk, etc., but my findings are that it's pretty slow.My downloaded test collada model is a non-animated ~15000 vertex object (which is actually a version of the chief from Halo) which is made up of around 90 meshes.  All I'm importing at the moment are its vertices and normals.  Using the ColladaDOM from c++, it seems to take an age to load the model, like minutes rather than seconds.  I'm running in debug mode at the moment, so I'd expect a fair speed up in release, but it certainly isn't going to be anywhere near usable.  I know xml loading/parsing can be slow but I would have thought the ColladaDOM to be fairly efficient - although I haven't done any granular timings yet so I can't see where in the process the bottleneck is.I have two questions regarding this:1) I know it's probably specific to the application that created (or exported) the model, but why would the model be split up into so many meshes?  I'm assuming it is because of materials/effects, and it looks that way from the xml, but there are separate meshes in there that share the same material.  I would have expected a human-like model like this to have only one mesh, with a lookup table for materials (e.g. attributes on a dx mesh) - this would make loading it much faster.2) Where Collada is used commercially, would the dae (xml) files be loaded and converted by the game engine (or game) or would there be another process in the pipeline which converts from a Collada dae file to something which the game engine can load quicker, i.e. some kind of deserialization from a binary object straight into game engine-friend objects?   
  You game definitely shouldn't load collada files directly, your engine/game should strip out just the bits of that file it needs in advance (and save it in an easy-to-load format).A Collada pipe should look somewhat like:DCC (e.g. 3dsMax) -> Export -> Fat data (e.g. Collada) -> Export (game specific) -> Slim data (game specific) -> Runtime (your game).   ;Quote:DCC (e.g. 3dsMax) -> Export -> Fat data (e.g. Collada) -> Export (game specific) -> Slim data (game specific) -> Runtime (your game).Thanks for the response.  What would be the idea behind the extra data step in the pipeline (post Collada)?  Would it not be easier to take the Collada format (the fat xml data) and export that directly into the 'slim data'?   ;Quote:Thanks for the response. What would be the idea behind the extra data step in the pipeline (post Collada)? Would it not be easier to take the Collada format (the fat xml data) and export that directly into the 'slim data'?It allows any 3d package that can export Collada files to be "supported" by your engine. For example, if you invest in a team of modellers, they might all have different preferences for their modeling package. As long as that package can export to a COLLADA file, you're all good.That is unless you write an exporter that creates the optimized file for each modelling package your team may use. This can really add up though.You should also take a look at FBX. I prefered it to collada. It was faster and easier to use in my opinion. But I eventually just ended up creating my own exporter for 3ds Max that exports straight out into the optimized file. Mainly becuase it'll probally only ever be me using my own engine :P   ;Quote:It allows any 3d package that can export Collada files to be "supported" by your engineThanks, wforl.  I understand that bit, I was wondering why you would need 2 interim formats between the Collada xml file (that all/most DCC packages can export to) and the game engine:Quote:Fat data (e.g. Collada) -> Export (game specific) -> Slim data (game specific) -> Runtime (your game)..namely, Export (game specific) and Slim data (game specific).Although I suspect I have just misread it and 'Export (game specific)' is the process rather than the data, so it would be (showing formats only):DCC -> Collada -> Engine-readyI'll have a look at FBX too though, thanks   ;  oh sorry. Misunderstood you. But yeah, do give FBX a go. For one thing you can export in both ascii and binary, so that would help in loading times   ;Quote:Original post by RobMaddisonI was wondering why you would need 2 interim formats between the Collada xml file (that all/most DCC packages can export to) and the game engine:.....namely, Export (game specific) and Slim data (game specific).Although I suspect I have just misread it and 'Export (game specific)' is the process rather than the dataYeah sorry, I didn't explain that too well.So the first 'Export' is the Collada exporter built into (or added on to) your DCC tool.The second one, 'Export (game specific)' is a tool that you write that can take collada files exported from any DCC and converts them to your slim format.   ;Quote:Original post by wforlIt allows any 3d package that can export Collada files to be "supported" by your engine. For example, if you invest in a team of modellers, they might all have different preferences for their modeling package. As long as that package can export to a COLLADA file, you're all good.Sounds good in theory, but in practice this usually doesn't work. Reason being the very restricted common profiles, the ill-formed and primitive default shader concepts in Collada, and the resulting need to use extra tags and custom profile/technique tags for any real world scenario.For each supported content creation tool, you will still need to supply custom code (plugin/script) which will insert additional data used by your engine as extra tag sections or custom profiles into the Collada. Depending on your content creation tool, this may not even be possible, so a completely new Collada exporter might be needed. While you're doing this, you could just as well directly export to a more suitable format for your engine.;  Thanks guysI'm just trying to understand the Collada format a bit more and I'm confused by something in my test data.In the model I've been testing with (I'm not sure how it was exported to Collada or what from), I have 90 <geometry> elements.  Over those 90 elements, there a total of 6 referenced materials.Most of the <geometry> elements have only one <triangles> element, but there are 6 that have two <triangles> elements which reference different materials.I can understand this, there's one particular two-<triangles> mesh with 89 vertices - 84 triangles have material 'A' and 32 triangles have material 'B'. (Because those figures don't add up, there must be some vertex sharing going on.)My question is, material 'A' and material 'B' are used throughout other <geometry> elements which have only one <triangles> element, so why is that?Is it simply because the designer of the object, in the DCC package, created a number of meshes, some with only one material, some with two materials and saved them and exported them as a group?I would have thought with this particular model (a humanoid) there would be one whole <geometry> element, with one <mesh>, one set of vertices and lots of <triangles> elements, each with references to the different materials - as there are 6 referenced materials overall, I'd expect 6 <triangles> elements.I understand this is probably only understandable to Collada verterans, but I'd really appreciate some help in understanding it.  I think the probable answer is to get some DCC software that can export to Collada and try out different models myself, but I'd be interested in hearing anyone's thoughts...Actually the main reason I'm asking is because of how I'm preparing to convert my Collada files into engine-ready object files.  If, when I come to do my modelling, I'm able to meld all vertices together into one whole mesh and just reference certain materials from certain triangles and the Collada exporter exports only one <geometry> node, then I think I've answered my own question.  I'm just really talking about models that would normally be one mesh, e.g. humanoids - things that have seperate meshes by their nature, i.e. a table with four chairs, that appear in the Collada file with 5 <geometry> nodes, is understandable.   ;Quote:Original post by RobMaddisonMy question is, material 'A' and material 'B' are used throughout other <geometry> elements which have only one <triangles> element, so why is that?There is nothing in the Collada spec that would define how meshes, objects or subobjects relate to the tag sections you mentioned. A DCC package is entirely free to map its internal SG or object representation to any number of Collada meshes, primitive tags (triangles, polygons, etc) and material tags, as it sees fit. You should not rely on any specific organization of such content in the Collada file. For the same scene, it can (and will !) be different between DCC packages and Collada exporters. You won't believe the insanely weird stuff some DCC and CAO/CAM tools spit out as Collada. In extreme cases, a DCC package could export your entire scene as a single <mesh> element, with a separate <triangle> tag for each single face in the scene (and yes, I have seen this...)The only thing you can rely on is that when processing the <scene> tag, you will get a valid scene description. Anything beyond that is entirely tool dependent.