Currently, when the coordIndex attribute of an IndexedLineSet contains a
polyline with > 2 indices, X3DGeoHelper::coordIdx_str2faces_arr() will
incorrectly determine the primitive type to be aiPrimitiveType_TRIANGLE or
aiPrimitiveType_POLYGON instead of aiPrimitiveType_LINE.
To fix this, this commit adds functions to explicitly handle an IndexedLineSet.
Fixes#3101
Several places in the code call `std::vector<aiVector3D>.emplace_back(0, 0, 0)`. The constructor of `aiVector3D` actually expects arguments of the type `ai_real`, (alias of `float` if compiling without `ASSIMP_DOUBLE_PRECISION`) but the literal `0` is of type `int`.
`emplace_back()` does support promotion, but `int` to `float` is a potentially lossy conversion. tl;dr: On warning level 4, MSVC spits out a very deeply nested `warning C4244: 'argument': conversion from '_Ty' to 'TReal', possible loss of data with _Ty=int and TReal=ai_real`.
This commit does not add or remove c’tors or d’tors, so it is *not* ABI-breaking.
If a c’tor/d’tor does nothing else than the default behavior, this commit replaces it with “= default”.
If an initializer list entry does nothing else than the default behavior, this commit removes it. First and foremost, remove default c’tor calls of base classes (always called by the compiler if no other base c’tor is explicitly called) and c’tor calls of members with complex types (e.g. “std::vector”).
In a few instances, user-defined copy c’tors / move c’tors / assignment operators / move assignment operators were replaced with “= default”, too. I only did this if I had a clear understanding of what’s going on.
Related: https://github.com/assimp/assimp/issues/4201
while the crashes go away, i'm not sure whether this is the correct fix.
also, afaict the X3D importer produces wrong results anyhow
using the pre-existing and well-tested GetExtension() (which happens
to also normalize the extension), rather than attempting our own
buggy one...
Closes: https://github.com/assimp/assimp/issues/4177