* Added more Maya materials
Added Maya materials to list and add setting texture properties for getting lost textures to mesh
* Update utMaterialSystem.cpp
Now new enumerators are handled by a case label in utMaterialSystem.cpp
* Update material.h
- Fix tests: use the correct max material parameter
---------
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
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>
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.
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.
Kim Kulling
Haixi
Sanchikuuus
Kimbatt
Julian Knodt
ycn2022
Kristjan Skutta
sSsA01
Stephen Gold
Maksim Kostin
IOhannes m zmölnig
Kim Kulling
Kim Kulling
Florian Born
Kawashima Satoshi
Alex
Gargaj
Jan Krassnigg
sfjohnston
Scott Johnston
Jackie9527
Suhajda Tamás