mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-05-14 00:52:04 +00:00
* 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; *21116995d7* https://github.com/prusa3d/PrusaSlicer/issues/13608 * https://github.com/prusa3d/PrusaSlicer/pull/13609 *e3c277b9eeFor 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>
96 lines
3.1 KiB
C++
96 lines
3.1 KiB
C++
// This file is part of libigl, a simple c++ geometry processing library.
|
|
//
|
|
// Copyright (C) 2024 Alec Jacobson <alecjacobson@gmail.com>
|
|
//
|
|
// This Source Code Form is subject to the terms of the Mozilla Public License
|
|
// v. 2.0. If a copy of the MPL was not distributed with this file, You can
|
|
// obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
#ifndef IGL_PLAINMATRIX_H
|
|
#define IGL_PLAINMATRIX_H
|
|
#include <Eigen/Core>
|
|
|
|
#include <type_traits>
|
|
#include <Eigen/Dense>
|
|
|
|
// Define void_t for compatibility if it's not in the standard library (C++11 and later)
|
|
#if __cplusplus < 201703L
|
|
namespace std {
|
|
template <typename... Ts>
|
|
using void_t = void;
|
|
}
|
|
#endif
|
|
|
|
|
|
#ifndef IGL_DEFAULT_MAJORING
|
|
#define IGL_DEFAULT_MAJORING Eigen::ColMajor
|
|
#endif
|
|
|
|
namespace igl
|
|
{
|
|
template <typename Derived, int Rows, int Cols, int Options>
|
|
struct PlainMatrixHelper {
|
|
using Type = Eigen::Matrix<typename Derived::Scalar,Rows,Cols,((Rows == 1 && Cols != 1) ? Eigen::RowMajor : ((Cols == 1 && Rows != 1) ? Eigen::ColMajor : Options))>;
|
|
};
|
|
template <typename Derived, typename = void>
|
|
struct get_options {
|
|
static constexpr int value = IGL_DEFAULT_MAJORING;
|
|
};
|
|
|
|
template <typename Derived>
|
|
struct get_options<Derived, std::void_t<decltype(Derived::Options)>> {
|
|
static constexpr int value = Derived::Options;
|
|
};
|
|
/// Some libigl implementations would (still do?) use a pattern like:
|
|
///
|
|
/// template <typename DerivedA>
|
|
/// void foo(const Eigen::MatrixBase<DerivedA>& A)
|
|
/// {
|
|
/// DerivedA B;
|
|
/// igl::unique_rows(A,true,B);
|
|
/// }
|
|
///
|
|
/// If `DerivedA` is `Eigen::Matrix`, then this may compile, but `DerivedA` might be
|
|
/// from a Eigen::Map or Eigen::Ref and fail to compile due to missing
|
|
/// construtor.
|
|
///
|
|
/// Even worse, the code above will work if `DerivedA` has dynamic rows, but will
|
|
/// throw a runtime error if `DerivedA` has fixed number of rows.
|
|
///
|
|
/// Instead it's better to declare `B` as a `Eigen::Matrix`
|
|
///
|
|
/// Eigen::Matrix<typename DerivedA::Scalar,Eigen::Dynamic,DerivedA::ColsAtCompileTime,DerivedA::Options> B;
|
|
///
|
|
/// Using `Eigen::Dynamic` for dimensions that may not be known at compile
|
|
/// time (or may be different from A).
|
|
///
|
|
/// `igl::PlainMatrix` is just a helper to make this easier. So in this case
|
|
/// we could write:
|
|
///
|
|
/// igl::PlainMatrix<DerivedA,Eigen::Dynamic> B;
|
|
///
|
|
/// IIUC, if the code in question looks like:
|
|
///
|
|
/// template <typename DerivedC>
|
|
/// void foo(Eigen::PlainObjectBase<DerivedC>& C)
|
|
/// {
|
|
/// DerivedC B;
|
|
/// …
|
|
/// C.resize(not_known_at_compile_time,also_not_known_at_compile_time);
|
|
/// }
|
|
///
|
|
/// Then it's probably fine. If C can be resized to different sizes, then
|
|
/// `DerivedC` should be `Eigen::Matrix`-like .
|
|
// Helper to check if `Options` exists in Derived
|
|
|
|
// Modify PlainMatrix to use get_options
|
|
template <typename Derived,
|
|
int Rows = Derived::RowsAtCompileTime,
|
|
int Cols = Derived::ColsAtCompileTime,
|
|
int Options = get_options<Derived>::value>
|
|
using PlainMatrix = typename PlainMatrixHelper<Derived, Rows, Cols, Options>::Type;
|
|
|
|
}
|
|
|
|
#endif
|