Previously, the default extruder wasn't handled inside multi-material segmentation, but this could confuse users, especially for multi-volume objects.
Because with multi-volume, it could happen that in the place where two volumes were touching, there could be a change in the used extruder.
* 1. Remove all global include_directories.
* 2. Move 3d party dependencies from src to budled deps if possible.
* Unify and enforce one way of including headers:
e.g. #include "libslic3r/GCode.hpp" vs #include "GCode.hpp"
(always use the "libslic3r/GCode.hpp" option).
* Make all dependencies (also header only) a cmake target.
Limit file size of .rels
Remove unneccesary end tag processing
Skip errors from loadind relations(to support previous behavior without .rels file)
Fix not setted PPath in component.
Add support for PPath in build item
The crash was introduced in 040a846, which completely threw away handling of the return value
of the importer.load_model_from_file function and replaced it with weaker condition. The purpose
of that change was to solve #8401 (missing error message when loading different invalid 3MF).
This commit reverts that change (and reintroduces #8401). Handling of 3MF loading errors
should be inside the importer.load_model_from_file function, where the check should be
added later.
Previous algorithms assume that they can get an invalid Voronoi diagram. Because of that, during the multi-material segmentation, a copy of the Voronoi diagram was created, and there were several attempts to fix missing vertices and edges. But as it shows, this wasn't a good enough approach and sometimes led to several issues like bleeding layers.
After generalization, our approach for detection and repairs of invalid Voronoi diagrams from Arachne, we could assume that multi-material segmentation gets non-invalid Voronoi diagrams.
With this assumption, we reimplement multi-materials segmentation to work directly on the Voronoi diagram. That should make multi-material segmentation more stable.
So, this should fix several issues like bleeding layers. Also, memory consumption should decrease by a lot. Also, there should be some speedup of multi-materials segmentation.
../src/libslic3r/Format/3mf.cpp:953:21: error: â€const string’ {aka â€const class std::basic_string<char>’} has no member named â€_Starts_with’
../src/libslic3r/Format/3mf.cpp:686:37: error: 'path' is not a member of 'boost::filesystem'; did you mean 'boost::property_tree::path'?
../src/libslic3r/Format/3mf.cpp:2437:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2445:36: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2455:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2464:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2473:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2482:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2491:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2500:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2506:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2515:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2524:36: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2535:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2541:32: error: 'remove' is not a member of 'boost::filesystem'
../src/libslic3r/Format/3mf.cpp:2650:62: error: 'path' is not a member of 'boost::filesystem'; did you mean 'boost::property_tree::path'?
../src/libslic3r/Format/3mf.cpp:3315:129: error: 'path' is not a member of 'boost::filesystem'; did you mean 'boost::property_tree::path'?
