When using python3 and running any of the provided scripts I get:
NameError: name 'unicode' is not defined. Python3 does not have unicode. Using try-except method helps to support python3
Commit 704e57db4e changed the order
of the parameters to `pyassimp.load`. The new order groups
`filename` and `file_type` which is preferable, but the samples and
other calls to `load` still point to the old order. This fixes that
with named arguments where necessary.
This reverts commit 33bd5cfcfb.
Installing the assimp library from setup.py is *not* a good idea as
it will break every packaging effort.
Besides, the original commit relies on an hard-coded path to find the
library that may not exist.
pyassimp returned a list instead of a numpy array when the normals were
empty. This also applies to texture coordinates and other stuff which is
explicitly converted in _finalize_mesh.
64-bit Compatibility:
The first four characters of a String material property would be cut
off. A String's length is defined in structs.py as a c_size_t
variable, which is 8 bytes wide on 64-bit Python. However, when an
aiString is used as an aiMaterial property in C/C++, the length is
truncated down to a 4-byte value on 64-bit machines (see
MaterialSystem.cpp aiMaterial::AddProperty() for details). A new
struct was declared in structs.py (MaterialPropertyString) and used
in core._get_properties().
Python 3.3 Compatibility:
The built-in function hasattr() changed in Python 3.2 to not
trap exceptions, which means a NULL pointer ValueException now
escaped when checking if a pointer was valid (hasattr(obj,
'contents') in core.call_init()) (see
http://bugs.python.org/issue9666 for details). A new helper
function was defined that preserves the legacy functionality of
trapping the exceptions (helper.hasattr_silent()) and used
throughout the code as a replacement for hasattr().
String objects would import as "bytes" rather than as a
string. This was most noticeable in the key names for
material properties, where the trailing ' of a bytes object
would remain after it was converted to a string. The
solution was to call decode() on the bytes object using
utf-8 decoding. This applies to various parts of core.py.
Closes#35