[Soc-2009-dev] Weekly report - Collada module

[Sebastian]

Hello all,
just a short introduction: we are the maintainers of the MIT license 
based COLLADA Exporter and Importers for 3ds Max and Maya. Both are 
(more or less) comparable to Blender and a joined effort to implement a 
working toolchain between all three DCC tools would be a great success. 
  To ease the difficulties that can arise when implementing COLLADA we 
have been developing several assisting APIs and libraries to read and 
write DAE files.

COLLADA Stream Writer
http://opencollada.svn.sf.net/viewvc/opencollada/trunk/COLLADAStreamWriter/

The stream writer is a helper framework to write valid 1.4 and 1.5 files 
on the fly without having to fill a in memory model first. It's the 
basis for the Max and Maya DAE exporters. It has some specialized 
functions for ftoa() and uses either fprintf (on windows) or a 
std:stream on unix depending on which specific implementation is faster.

COLLADA Sax Parser
http://opencollada.svn.sf.net/viewvc/opencollada/trunk/

The base of the parser is an auto generated, validating, COLLADA 
specific, xml parser, that alternatively uses libXml or expat. The c++ 
code for this parser is generated from the COLLADA XSD by a java 
program. This parser has callback functions for each COLLADA element 
(SAX style parsing). One for the beginning of each element, one for the 
end of each element and, if character data is allowed inside this 
element, also one for that data. The begin functions parse the 
attributes, if any, convert them to the corresponding c++ data type 
according to the XSD and provide them in a struct. The names of the 
members in this struct correspond to the attribute names in COLLADA. 
Similarly, the parser parses the character data, if any, inside 
elements, converts it to the corresponding c++ data type according to 
the XSD and calls the data function with these values stored in an 
array. Since sax based xml parser do not necessarily pass all character 
data at once, that data function might be called multiple times for one 
element and provide the data in pieces (e.g. large float arrays are 
passed during several calls).
The end function is called when the element is closed and has no parameters.

On top of this auto generated parser we have implemented two more 
components. A data model (currently called COLLADAFramework) and a 
COLLADA parser (loader) which fills that model (currently called 
COLLADASaxFrameworkLoader).
The data model consists of atomic objects (Geometry, Scenegraph, 
LibraryNodes ... ) which are passed to any software that wants load a 
dae file using this loader. To receive the objects, this software needs 
to implement the COLLADAFW::IWriter interface. The loader then calls the 
methods of this interface, as soon as an atomic object has been loaded 
completely, e.g. the writeGeometry method is called as soon as the 
end_geometry function of the generated
sax parser has been called. Therefore, the atomic objects are passed in 
the order they appear in the dae file, which requires that implementers 
must be able to handle them in arbitrary order. If this is not possible, 
one can parse the dae file more than once. For instance the COLLADAMaya 
plug-in uses this technique, since it needs to know the scene graph, 
before it can handle geometries. The methods of the interface pass 
pointers to the objects that are only
valid inside the call of this method. As soon as this method returns, 
the object might be deleted and the pointer becomes invalid. This 
approach reduces the memory consumption, since it needs to hold only one 
atomic object in memory a at time. Each atomic object has a unique id 
used to match objects and references to them. The 
COLLADASaxFrameworkLoader already resolves urls in COLLADA and uses them 
to assign these unique ids.

There is a very simple sample implementation for the Sax Parser 
available that converts DAE files into binary Ogre3D meshes that might 
server as a starting point for the Blender efforts.
http://opencollada.svn.sourceforge.net/viewvc/opencollada/trunk/dae2ogre/

These libraries are all extremely fast (500MB DAE file parsing takes ~2 
sec) and have not memory overhead. The SAX based approach is a bit more 
difficult to handle but the framework allows you to create an importer 
more reliable and faster than with the COLLADA DOM libraries.

BTW, COLLADA allows arbitrary polygons with and without holes, convex 
and concave ones. Triangulation is not a trivial task for those - i'd 
support only triangles, tristrips and trifans in the very first step.

Sebastian



Chingiz Dyussenov wrote:
> I have read first chapters of Collada spec 1.5, now I have the idea of 
> it's fundamentals, how it represents geometry. Collada allows polygons 
> with more than 4 vertices. In Blender faces are made by only 3 or 4 
> vertices. I will convert all polygons to triangles for now.
> 
> Got acquainted with the basics of Collada DOM.
> 
> Had a short introduction to Blender operator basics and menus based on 
> operators. Now I know how to use addvertlist, addfacelist functions to 
> construct meshes.
> 
> I talked to my mentor about where in Blender to put Collada DOM library 
> and my sources. Here is the directory blender/source/blender/collada.
> 
> I am going to start coding the geometry part, import/export vertices 
> with normals, uvs and colors.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Soc-2009-dev mailing list
> Soc-2009-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2009-dev