When loading a mesh exported from assimp into Blender, it warns that it has an incorrect class.
While debugging, I traced it back to this being `Blendshape` where `Geometry` was expected. This
is likely because this node describes a `Geometry`, which is used as a blendshape. I'm not sure
if any other DCC tools or places to import it expect `Blendshape` instead (i.e. was this code
ever tested?), but it fixes its use in Blender.
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
* Update XFileImporter.cpp
Comment out boneIdx conditional which caused massive breakage
* Update XFileImporter.cpp
Fix typo
* Update XFileImporter.cpp
Dummy whitespace change to attempt to re-trigger failing CI tests
---------
Co-authored-by: Steve M <praktique-tellypresence@yahoo.com>
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
The previous table was in an incorrect order, leading to index references in DXF producing the wrong colours when converted.
Also added other entries to bring the total number of ACI colours up to the number that can be used in DXF files
Changed order of operations for insert positioning and scaling. Need to position the inserts before scaling it, otherwise the position ends up up being position*scale
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
The regression was introduced in 904f17f.
Since all the cases are now fully handled at the child level,
visiting the whole subtree is changed into iteration over the children.
Previously was reading a uint, which always failed. Since the output was never checked, this
seemed to work, and works fine for most models since they only use UV channel 0.
It seems that rotation matrices later expect radians.
This conversion breaks it, and was validated on the conversion of
`cesium_man.glb` --> `cesium_man.fbx`
Failed to get floating values (e.g. opacity) from scene material when ASSIMP_DOUBLE_PRECISION is defined, so they are not reflected to output fbx file.
Allows to export unlimited (more than 4) bones per vertex
Use JOINTS_1,2,.. and WEIGHTS_1,2,...
Added AI_CONFIG_EXPORT_GLTF_UNLIMITED_SKINNING_BONES_PER_VERTEX flag
This commit adds two classes:
* ProgressTracker
* ProgressScope
The first is for users to implement, and to instantiate when they desire
to get informed about the overall progress.
The second is to be added to all functions that may take a considerable
amount of time, such that they can report back how far along they are.
These are much more convenient to use than the existing ProgressHandler.
ProgressScope is designed such that it only requires "local knowledge"
about upcoming and finished work. Scopes are nested and combined to
form the final global progress.
The active ProgressTracker is stored in a thread_local pointer.
This is a consicius decision since in assimp there is often no 'context'
passed through. The ProgressTracker may be needed anywhere, and it would
be tedious and a huge change to pass it through to every function.
Therefore, using a thread_local variable makes it accessible everywhere,
without a major interface change. Since assimmp is single-threaded,
but may be run in parallel on multiple threads, a thread_local is a
good trade-off, in my opinion.
This change only adds few uses of ProgressScope, to generally show how
it would be used. Also for our use cases these where the most pressing
places to add progress reporting, so this already covers loading from FBX
files pretty well.