- doc: clarify wording in bone section.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1101 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
Fix a compiler warning.


git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1102 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
- assimp export: fix small issue when guessing output file format. See https://sourceforge.net/projects/assimp/forums/forum/817653/topic/4922378

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1103 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
# TextureTransform-Step: fix memory leak due to uvtrafo keys not being deleted properly. This fixes [3463286].

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1104 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
merge git://github.com/gellule/assimp.git
the strings used in materials and elsewhere in assimp. Because of this,
in PyAssimp3 strings in materials don't work properly on 64 bits
platforms. This commit adds a StringUInt32 ctypes structure and use it
in GetMaterialProperties as a workaround.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1105 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
merge git://github.com/gellule/assimp.git

Before, neither the texture index nor its semantic were kept in the
returned output. Now GetMaterialProperties returns a (name, color,
material, texture) tuple. Name is the name of the material. Color is a
dictionary of color properties. Material is a dictionary of material
properties. Textures is a triply nested dictionary addressed by the
following: textures[index][semantic][key]. See assimp documentation for
the meaning of index, semantic, and keys in general.



git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1106 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
Fix [3472310] Unnecessary output in LWOImporter 

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1107 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
[ 3460982] Patch for Bug 3460978 - Obj loader not generating new objects for material groups.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1108 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
Fix [3472966] "The public include export.h has a reference to boost"
See http://sourceforge.net/tracker/?func=detail&atid=1067632&aid=3472966&group_id=226462

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1109 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
+ add aiString::C_Str

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1110 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
- Redesign the C interface to allow per-import settings.
- Make C-API threadsafe even without boost (no longer a global importer <-> scene map).
- Cleanup headers.
- Change the way how Importer::pimpl is accessed - all users are no longer friends of Importer to avoid spoiling the public interface. Rather, pimpl is exposed via a public member function and anyone having the definition of ImporterPimpl can access it.

THIS IS A BREAKING API CHANGE for anyone using properties with the C API. It is, however, a huge step forward and finally makes our C API functionally equivalent to the C++ interface.

I hope we can adapt all ports as soon as possible. I'd be grateful if the respective maintainers could do this.

Documentation is not yet up to date.

All this is in anticipation to the upcoming 3.0 release, which I'm actively working on.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1111 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
- update README.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1112 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
Apply patch [3473792] - LWS loader failed to find LWO files referenced with inaccessible, absolute paths, but actually residing in the folder of the LWS file. Applied the patch to FileSystemFilter, so all loaders do this now.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1113 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
# IFCLoader: < predicate to order representations by use for us was accidentally a total ordering.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1114 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
+ add poly2tri to assimp repository.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1115 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
+ add polyclipper to assimp repository.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1116 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
# poly2tri: add missing <stdexcept> 

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1117 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
- Ifc: use a combination of clipper and poly2tri to triangulate arbitrary polygons with arbitrarily-shaped holes (the former to workaround the cases not supported by the latter ...). Issues with doors et al. (i.e. openings touching the outer contour of a wall polygon) remain and are yet to be solved. Overall, this change should make IfcLoader much more robust, though. Since this means that the previous algorithm to triangulate walls is dropped altogether, regressions are highly likely. 

Note 1: there are cases in which the previous algorithm may have produced 'better' triangles, but my big hope is that poly2tri's CDT implementation will implement more advanced refinement algorithms over time.

Note 2: This issue http://code.google.com/p/poly2tri/issues/detail?id=34 is relevant, first versions of my poly2tri embedding would indeed stackoverflow or assert. I somehow avoided this by using Clipper as prepass and scaling the entire polygon to 0..1 range (as recommended).


git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1118 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
# DXFLoader: EOLs.

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1119 67173fc5-114c-0410-ac8e-9d2fd5bffc1f
# fix vc9 pch settings

git-svn-id: https://assimp.svn.sourceforge.net/svnroot/assimp/trunk@1120 67173fc5-114c-0410-ac8e-9d2fd5bffc1f