This is possible, if the option "aiProcess_ValidateDataStructure" is deactivated as postprocessing step, but the option "aiProcess_FindDegenerates" is activated and the mesh contains invalid data structures
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
* Allow empty slots in aiMesh::mTextureCoords.
1.Explicitly say in documentation that empty slots are allowed (it was unclear).
2.Change GetNumUVChannels() implementation to allow empty slots.
3.Revert fraction of 2da2835b29 where empty slots are detected and error logged.
* Fix#5632 by reverting fraction of d6aacefa1e where Collada texcoords are renumbered to avoid empty slots.
---------
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
This commit fixes some bool loads which are not initialized. With ubsan and the "option -fsanitize=bool", this results in a runtime error during test execution.
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
* Reverts the changes introduced by commit ad766cb in February 2022.
Explanation why the old code was just fine is given in Q&A #5512.
* Added that missing ;
---------
Co-authored-by: Kim Kulling <kimkulling@users.noreply.github.com>
- std::min/max were not defined in StackAllocator.inl; Also added explicit template arguments to break macro expansion if Windows.h is included prior and NOMINMAX macro is not present.
- Made static_assert statements compatible with C++11 in ProcessHelper.cpp.
- Removed unused string_view include in ObjFileParser.cpp.
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
Matthias Möller
JensEhrhardt-eOPUS
Stepan Hrbek
Johannes Unterguggenberger
Succ3s
Stephen Gold
Laura Hermanns
Kim Kulling
Kim Kulling
ockeymm
Aaron
Jan Krassnigg
Alex
Kristjan Skutta
Suhajda Tamás
Jackie9527
Turo Lamminen