diff --git a/doc/AssimpDoc_Html/AssimpDoc.chm b/doc/AssimpDoc_Html/AssimpDoc.chm index c6e5c9c11..2c641027f 100644 Binary files a/doc/AssimpDoc_Html/AssimpDoc.chm and b/doc/AssimpDoc_Html/AssimpDoc.chm differ diff --git a/doc/dox.h b/doc/dox.h index d58bea9c9..d7a4ec735 100644 --- a/doc/dox.h +++ b/doc/dox.h @@ -28,7 +28,8 @@ that it has not been implemented yet and some (most ...) formats lack proper spe 3D Studio Max ASE ( *.ase )
Wavefront Object ( *.obj )
Stanford Polygon Library ( *.ply )
-AutoCAD DXF ( *.dxf ) 2
+AutoCAD DXF ( *.dxf )
+IFC-STEP ( *.ifc )
Neutral File Format ( *.nff )
Sense8 WorldToolkit ( *.nff )
Valve Model ( *.smd,*.vta ) 3
@@ -794,7 +795,7 @@ set if ASSIMP is able to determine the file format. @section General Or - how to write your own loaders. It's easy. You just need to implement the #Assimp::BaseImporter class, -which defines a few abstract methods, register your loader, test it carefully, and provide test models for it. +which defines a few abstract methods, register your loader, test it carefully and provide test models for it. OK, that sounds too easy :-). The whole procedure for a new loader merely looks like this: @@ -827,7 +828,7 @@ Just copy'n'paste the template from Appendix A and adapt it for your needs. with DefaultLogger::get()->[error, warn, debug, info].
  • -Make sure the loader compiles against all build configurations on all supported platforms. This includes -noboost! To avoid problems, +Make sure that your loader compiles against all build configurations on all supported platforms. This includes -noboost! To avoid problems, see the boost section on this page for a list of all 'allowed' boost classes (again, this grew historically when we had to accept that boost is not THAT widely spread that one could rely on it being available everywhere).
    • @@ -852,7 +853,8 @@ store the properties as a member variable of your importer, they are thread safe @@ -1575,24 +1577,60 @@ Automatic multi-threading is not currently implemented. */ /** -@page importer_notes Importer Notes +@page importer_notes Importer Remarks +
    @section blender Blender + +This section provides remarks and implementations notes regarding Assimp's Blender3D importer. @subsection bl_overview Overview -Assimp provides a self-contained reimplementation of Blender's so called SDNA system (http://www.blender.org/development/architecture/notes-on-sdna/). +The library provides a self-contained reimplementation of Blender's so called SDNA system (http://www.blender.org/development/architecture/notes-on-sdna/). SDNA allows Blender to be fully backward AND forward compatible and to exchange files created on any of the various platforms blender runs on with any other. Quick processing is another design goal - -BLEND is a fully-fledged binary monster and Assimp tries to read the most of it. Naturally, if Blender is the only modelling tool -in your asset work flow, consider writing a custom exporter from Blender if Assimp's format coverage does not meet your requirements. +BLEND is a fully-fledged binary monster and the library tries to read the most of it. Naturally, if Blender is the only modelling tool +in your asset work flow, consider writing a custom exporter from Blender if Assimps format coverage does not meet your requirements. @subsection bl_status Current status +The Blender loader does not support animations yet, but is apart from that considered relatively stable and well-tested. + @subsection bl_notes Notes +When filing bugs on the Blender loader, always give the Blender version (or, even better, post the file that has caused the error). + +
    +@section ifc IFC + +This section provides remarks and implementations notes regarding Assimp's IFC-STEP importer. +@subsection ifc_overview Overview + +The library provides a partial implementation of the IFC2x3 industry standard for automatized exchange of CAE/architectural +data sets (i.e. buildings). See http://en.wikipedia.org/wiki/Industry_Foundation_Classes for more information on the format. We aim +at getting as much 3D data out of the files as possible. + +@subsection ifc_status Current status + +IFC support is new and considered experimental. Please report any bugs you may encounter. + +@subsection ifc_notes Notes + +- Only the STEP-based encoding is supported. IFCZIP and IFCXML are not (but IFCZIP can simply be unzipped to get a STEP file out ofit). +- The importer leaves vertex coordinates untouched, but applies a global scaling to the root transform to + convert from whichever unit the IFC file uses to metres. +- The importer does not currently skip geometric representations for entities which have multiple representations defined - it may happen that there +is finally more than one mesh describing the same IfcProduct. This should be an unlikely case, however, usually +if there are multiple representations, only one of them will actually be a solid 3d model. +- Not supported (but possible relevant for proper display of most files) are: revolved surfaces, binary clipped surfaces, + old-style transformations (as for IFC2), polygons with holes, textured surfaces and the various kinds of meta connections + provided by IFC: only aggregation, containment and material assignment relationships are resolved by the library and + mapped to the output node graph. +- The implementation knows only about IFC2X3 and applies this rule set to all models it encounters, regardless of their actual version. +
    @section ogre Ogre +This section provides remarks and implementations notes regarding Assimp's OgreXML importer. @subsection overview Overview Ogre importer is currently optimized for the Blender Ogre exporter, because thats the only one that i use. You can find the Blender Ogre exporter at: http://www.ogre3d.org/forums/viewtopic.php?f=8&t=45922