3 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
3 people	dc5897d7b5	Update eigen to v5.0.1 and libigl to v2.6.0. (#11311) ... * Update eigen from v3.3.7 to v5.0.1. This updates eigen from v3.3.7 released on December 11, 2018-12-11 to v5.0.1 released on 2025-11-11. There have be a large number of bug-fixes, optimizations, and improvements between these releases. See the details at; https://gitlab.com/libeigen/eigen/-/releases It retains the previous custom minimal `CMakeLists.txt`, and adds a README-OrcaSlicer.md that explains what version and parts of the upstream eigen release have been included, and where the full release can be found. * Update libigl from v2.0.0 (or older) to v2.6.0. This updates libigl from what was probably v2.0.0 released on 2018-10-16 to v2.6.0 released on 2025-05-15. It's possible the old version was even older than that but there is no version indicators in the code and I ran out of patience identifying missing changes and only went back as far as v2.0.0. There have been a large number of bug-fixes, optimizations, and improvements between these versions. See the following for details; https://github.com/libigl/libigl/releases I retained the minimal custom `CMakeLists.txt`, added `README.md` from the libigl distribution which identifies the version, and added a README-OrcaSlicer.md that details the version and parts that have been included. * Update libslic3r for libigl v2.6.0 changes. This updates libslic3r for all changes moving to eigen v5.0.1 and libigl v2.6.0. Despite the large number of updates to both dependencies, no changes were required for the eigen update, and only one change was required for the libigl update. For libigl, `igl::Hit` was changed to a template taking the Scalar type to use. Previously it was hard-coded to `float`, so to minimize possible impact I've updated all places it is used from `igl::Hit` to `igl::Hit<float>`. * Add compiler option `-DNOMINMAX` for libigl with MSVC. MSVC by default defines `min(()` and `max()` macros that break `std::numeric_limits<>::max()`. The upstream cmake that we don't include adds `-DNOMINMAX` for the libigl module when compiling with MSVC, so we need to add the same thing here. * Fix src/libslic3r/TriangleMeshDeal.cpp for the unmodified upstream libigl. This fixes `TriangleMeshDeal.cpp` to work with the unmodified upstream libigl v2.6.0. loop.{h,cpp} implementation. This file and feature was added in PR "BBS Port: Mesh Subdivision" (#12150) which included changes to `loop.{h,cpp}` in the old version of libigl. This PR avoids modifying the included dependencies, and uses the updated upstream versions of those files without any modifications, which requires fixing TriangleMeshDeal.cpp to work with them. In particular, the modifications made to `loop.{h,cpp}` included changing the return type from void to bool, adding additional validation checking of the input meshes, and returning false if they failed validation. These added checks looked unnecessary and would only have caught problems if the input mesh was very corrupt. To make `TriangleMeshDeal.cpp` work without this built-in checking functionality, I removed checking/handling of any `false` return value. There was also a hell of a lot of redundant copying and casting back and forth between float and double, so I cleaned that up. The input and output meshs use floats for the vertexes, and there would be no accuracy benefits from casting to and from doubles for the simple weighted average operations done by igl::loop(). So this just uses `Eigen:Map` to use the original input mesh vertex data directly without requiring any copy or casting. * Move eigen from included `deps_src` to externaly fetched `deps`. This copys what PrusaSlicer did and moved it from an included dependency under `deps_src` to an externaly fetched dependency under `deps`. This requires updating some `CMakeList.txt` configs and removing the old and obsolete `cmake/modules/FindEigen3.cmake`. The details of when this was done in PrusaSlicer and the followup fixes are at; * https://github.com/prusa3d/PrusaSlicer/commit/21116995d78b74dee69ce42874b643012a7c14e5 * https://github.com/prusa3d/PrusaSlicer/issues/13608 * https://github.com/prusa3d/PrusaSlicer/pull/13609 * https://github.com/prusa3d/PrusaSlicer/commit/e3c277b9eea0ca25e90e2378bcda198d56c4d304 For some reason I don't fully understand this also required fixing `src/slic3r/GUI/GUI_App.cpp` by adding `#include <boost/nowide/cstdio.hpp>` to fix an `error: ‘remove’ is not a member of ‘boost::nowide'`. The main thing I don't understand is how it worked before. Note that this include is in the PrusaSlicer version of this file, but it also significantly deviates from what is currently in OrcaSlicer in many other ways. * Whups... I missed adding the deps/Eigen/Eigen.cmake file... * Tidy some whitespace indenting in CMakeLists.txt. * Ugh... tabs indenting needing fixes. * Change the include order of deps/Eigen. It turns out that although Boost includes some references to Eigen, Eigen also includes some references to Boost for supporting some of it's additional numeric types. I don't think it matters much since we are not using these features, but I think technically its more correct to say Eigen depends on Boost than the other way around, so I've re-ordered them. * Add source for Eigen 5.0.1 download to flatpak yml config. * Add explicit `DEPENDS dep_Boost to deps/Eigen. I missed this before. This ensures we don't rely on include orders to make sure Boost is installed before we configure Eigen. * Add `DEPENDS dep_Boost dep_GMP dep_MPFR` to deps/Eigen. It turns out Eigen can also use GMP and MPFR for multi-precision and multi-precision-rounded numeric types if they are available. Again, I don't think we are using these so it doesn't really matter, but it is technically correct and ensures they are there if we ever do need them. * Fix deps DEPENDENCY ordering for GMP, MPFR, Eigen, and CGAL. I think this is finally correct. Apparently CGAL also optionally depends on Eigen, so the correct dependency order from lowest to highest is GMP, MPFR, Eigen, and CGAL. --------- Co-authored-by: Donovan Baarda <dbaarda@google.com> Co-authored-by: Noisyfox <timemanager.rick@gmail.com>	2026-05-12 15:09:13 +08:00
Donovan Baarda	f5bbe52ac9	Optimize FillTpmsFK using optimized MarchingSquares from #10747. (#10876) ... # Change FillTpmsFK.cpp to use MarchingSquares.hpp. This is still a work in progress, but it does seem to work fine, and I thought I'd put this up there for people to have a play with. I also have a few questions because I'm not 100% familiar with the rest of the codebase and I'm going to use the review of this to figure a few things out. This builds on #10747 which simplified and significantly optimized MarchingSquares.hpp by replacing most of FillTpmsFK.cpp's implementation to just use that marching squares implementation instead of re-implementing it's own. I don't yet have any solid speed comparisons but it feels a bit subjectively faster, though I think that most of the delay in previewing the slicing results is not in the fill-generation so it's a bit hard to tell. I don't know if there are any tests/benchmarks/etc that I could use for testing this, but I'm probably going to add some to this PR at some point. Even if this doesn't give a significant speed-up, it does significantly simplify the code and make it easier to re-use for other equation based fill-patterns. This could re-implement gyroid or TpmsD with about 5 lines of C code to inherit from `ScalarField` and redefine the `float get_scalar(coordf_t x, coordf_t y, coordf_t z)` function with the appropriate equation. I don't think it would be faster than the current gyroid or TpmsD fills though, since they directly generate a single line using the equation and then just copy and shift it. However, it might not be much slower and it would simplify the code to do them all the same way. But the main reason I'm doing this is this can be used to implement far more complicated fills that can't really be implemented any other way. In particular I'm working towards a gyroid fill that dynamically varies it's density based on how close it is to the walls. I have a bunch of questions about some of the other bits that I'll post as comments against the review-diff. # Screenshots/Recordings/Graphs I'll add some when I get there... but so far the results look identical to the previous implementation even when I zoom in close. <!-- > Please attach relevant screenshots to showcase the UI changes. > Please attach images that can help explain the changes. --> ## Tests <!-- > Please describe the tests that you have conducted to verify the changes made in this PR. -->	2025-10-25 11:17:43 +08:00
3 people	2a3e761ab9	Optimize and simplify MarchingSquares.hpp. (#10747) ... * Optimize and simplify MarchingSquares.hpp, and fix it's test. This changes the implementation to get the possible next directions for a cell when building the tags and clearing them as the cells are visited during the march, instead of adding the visited previous direction to the tags during the march. The Dir enum has been turned into bit flags that for the possible next directions with boolean operators for testing/setting/clearing them. This simplifies and optimizes many operations during the march and building the polygons. The complicated/broken and unused partial support for cell overlap has been removed, simplifying the overly confusing grid iteration logic. The broken test has been fixed by removing the now gone `RasterBase` namespace from `sla::RasterBase::Pixeldim` and `sla:RasterBase:Resolution`, and the CMakeLists.txt entry uncommented. make Dir into flags * Further optimize MarchingSquares.hpp and improve comments. * Switch from a single byte-vector containing tags and dirs for each cell to a m_tags vector of bit-packed tags for each grid corner and an m_dirs vector of packed 4bit dirs for each cell. Since each grid corner tag is shared by the 4 adjacent cells this significantly reduces storage space and avoids redundantly calculating each tag 4x. It also significantly improves memory locality with each phase of calculating tags, calculating dirs, calculating rings operating only on the tags or dirs data required without them being interleaved with the data they don't need. * Change NEXT_CCW to be initialized with a static constexpr lambda instead of a manually entered table. This avoids typo errors manually building the table. * Optimize search_start_cell() so it can efficiently skip over cleared blocks of 8 dirs in the packed m_dirs vector. * Change the tags logical labeling to better suit the packed tags vector data. This makes it a tiny bit more efficient to extract from the m_tags bitmap. * Remove the now unused SquareTag enum class. * Add comments explaining the algorithm, including corner-cases in cell iteration. * Remove unused Dir operators and get_dirs() argument, and clang-format. * Fix some bugs and add stream output operators for debugging. * Fix a bug building tags where `step(gcrd, Dir::right)` was not assigned to update the gcrd grid point. Perhaps this should be a mutating method, or even a += operator? Also when wrapping at the end of a row it was updating the gcrd grid point by mutating the p raster point instead of itself. Perhaps Grid and Raster points should be different types? Maybe even templated? * Fix a bug in get_tags() when the second row tags are packed into any of the 2 LSB's of the uint32_t blocks. In hind-sight obviously `>>(o - 2)` will not shift left when `o < 2`. * Move interpolation of the edge-crossings into a `interpolate()` method, and make it shift bottom and right side points "out" by one to account for raster pixel width. This makes the results track the raster shapes much more accurately for very small windows. * Make `interpolate_rings()` check for and remove duplicated points. It turns out it's pretty common that two edge-crossing-points at a corner interpolate to the same point. This can also happen for the first and last points. * For Coord add `==` and `!=` operators, and use them wherever Coord's are compared. * Add `<<` stream output operators for Coord, Ring, and Dir classes. Add `streamtags(<stream>)` and `streamdirs(<stream>)` methods for dumping the tags and dirs data in an easy to understand text format. These make print-debugging much easier. * Add `assert(idx < m_gridlen)` in a bunch of places where grid-indexes are used. * For test_clipper_utils.cpp fix three "ambiguous overloading" compiler errors. This just adds three `Polygons` qualifications to fix compiler errors about ambiguous overloaded methods. Note this file was formated with a mixture of tabs and spaces and had lots of trailing whitespace. My editor cleaned these up resulting in a large looking diff, but if you use `git diff -w` to ignore the whitespace changes you will see it is actually tiny. errros * Update SLA/RasterToPolygons.* for MarchingSquares.hpp improvements. Change the minimum and default window size from 2x2 to 1x1. Also remove the strange pixel size re-scaling by (resolution/resolution-1). The old MarchingSquares implementation had complications around a default minimum 1 pixel "overlap" between cells which messed with the scaling a tiny bit and meant when you requested a 2x2 window size it actually used a 1x1 window. Both of these meant you had to specify a window 1 pixel larger than you really wanted, and you needed to undo the strange scaling artifact for accurate dimensions of your results. This has been fixed/removed in the new implementation, so the window is the window, there is no overlap, and no strange miss-scaling. * Fix test_marchingsquares.cpp and add StreamUtils.hpp. This fixes the MarchingSquares unittests to both pass and be more strict than they were before. It also adds libslic3r/StreamUtils.hpp which includes some handy streaming operators for standard libslic3r classes used to show extracted polys in the unittests. * Change Format/SL1.cpp to support the min 1x1 window for MarchingSquares. * Fix the ring-walk termination condition. Terminate the ring-walk when we return to the starting cell instead of when we reach a cell with no remaining directions. This ensures we don't merge two polygons if we started on an ambiguous cell. * Revert the removal of duplicate points in interpolate_rings(). It turns out that duplicate points are only relatively common when using a 1x1 window. These happen when the line passes through the corner pixel on a top-left corner in the raster, and the probability of this rapidly declines as the window increases, so in many cases this filtering is just overhead. It can also be potentially useful to see the points for every edge crossing even if they are duplicates. This kind of filtering is already done and done better in the polygon post-processing. * rename `interpolate()` to `interpolate_edge()`, make it update the point in-place, and add asserts to ensure the input point is a valid edge interpolation point. * Remove the duplicate point filtering from `interpolate_rings()` and simplify it. * Optimize directions building. This optimizes `get_dirs_block8()` to rapidly skip over blocks where the tags produce no directions (all tags are 1's or 0's), and also to build the directions faster when it has to by fetching the whole blocks worth of tags at once instead of cell-by-cell. * Rename `get_tags()` to `get_tags9()` and make it fetch a row of nine tags instead of the tags for a single cell. * Optimize `get_dirs_block8()` to use `get_tags9()` to get the next nine tags for the current and next rows and then shift through them to generate the tags and directions for each cell in the block. Also abort early and just return an empty block if the tags are all 0's or all 1's. * Tiny optimization for `get_tags_block32()`. This avoids using the `step()` method for a simple step-right that can be done with a simple increment of the column. It also avoids re-calculating the raster-coodinates for every corner, instead incrementing the column by `m_window.c` until the end of a row. * Fix svg output in test_marchingsquares.cpp for recreate_object_from_rasters. These SVG's were not properly centered... * Fix 2 static_casts for compiling on Windows. Thanks to RF47 for pointing this out on the #10747 pull request. * Make edge iteration use O(ln(N)) binary search instead of linear. This should be much faster when the window size is large. * Make `CellIt` into a `std::random_access_iterator_tag` so that `std::lower_bound()` can use a binary search to find the point on the edge instead of a linear search. * Change `step()` to support an optional distance argument and make it modify the `Coord` in-place instead of return a new one. * Update tests for the `step()` change. * Add Catch2 BENCHMARK tests for MarchingSquares. This required enabling the benchmarks in the tests/CMakeLists.txt config. * Add a _Loop<> specialization for parallel execution using ExecutionTBB. This is something that could be added wherever you are going to use this, but I intend on using this in multiple places so we might as add this once in one place where it can be reused. * Fix whitespace in messed up by tab-replacements. My editor renders, and replaces, tabs as 8 spaces. This messed up the indenting in tests/libslic3r/CMakeLists.txt and tests/libslic3r/test_clipper_utils.cpp when I made tiny changes in them. This fixes the indenting using 4 chars. Note it will still show as a diff because it is replacing tabs with 4 spaces, and removing trailing whitespace. But at least it's now indented correctly... --------- Co-authored-by: Donovan Baarda <dbaarda@google.com> Co-authored-by: SoftFever <softfeverever@gmail.com>	2025-10-19 19:27:55 +08:00