- AssimpPCH.h appears to have been removed in #536
- There was a bug where if your model data had a null terminator, AndroidJNIIOSystem would incorrectly calculate the number of bytes it needed to write to the file (since it reads a compressed file from the Android assets, and then writes it to the internalDataPath directory for later importing)
The iOS 7.1 SDK isn't available anymore in the current version of Xcode, so the script doesn't work without modification.
By setting IOS_SDK_VERSION to an empty value, the script will default to a symlink* which always points to the latest installed SDK.
* /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
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
Kim Kulling
Brian Schwind
Alexander Gessler
Ser Lev Arris
Michael Dawson-Haggerty
Alexander Gessler
sth
enkore
Kim Kulling
xantares
Oliver Nagy
Filip Wasil
Ryan Cole
jmas-ogawa
shaded enmity
Seed-Of-Hate
autosquid
Eximius
Faule Socke
Bill Roeske