sgsellan/botsch-kobbelt-remesher-libigl

Implementation of the local remesher from "A Remeshing Approach to Multiresolution Modeling" by M. Botsch and L. Kobbelt, to work with the libigl geometry processing library

botsch-kobbelt-remesher-libigl's Issues

If no arguments print help

The program crashes if the caller doesn't give any input arguments. Perhaps instead it could catch this and spit out a help document or an example usage (e.g., copied from the README.md)

Running Two Remeshings in Parallel

Each time I try to run two remeshings in parallel, one of them stops and never ends. Is it a limitation of the code, or is there a bug in my code?

Installation problem

Hello!

I tried to install following the instructions:

mkdir build
cd build
cmake ..
make -j

cmake .. finishes successfully, however producing following warnings:

CMake Warning (dev) at ext/numpyeigen/cmake/numpyeigen.cmake:98 (set):
  Cannot set "NPE_ROOT_DIR": current scope has no parent.
Call Stack (most recent call first):
  CMakeLists.txt:23 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

Full cmake .. output is attached in
cmake_output.txt

Make -j fails with a lot of errors pretty similar to each other. E.g. first error is:

/home/vlad/botsch-kobbelt-remesher-libigl/ext/libigl/include/igl/diag.cpp:75:10: error: ‘DynamicSparseMatrix’ is not a member of ‘Eigen’
   Eigen::DynamicSparseMatrix<T, Eigen::RowMajor> dyn_X(V.size(),V.size());

Full make -j output is attached in
make_output.txt

Segmentfault occurs when the input triangle mesh has no-manifold edges

The problem talked about can be verified using any no-manifold mesh. Could you provide some advice to repair it? Thanks.

Error when building on windows

I'm unable to build the project on windows 10 (64 bit). I can complete the cmake command successfully and I see VS Studio projects generated. But when I try to build the projects I run into two errors:

Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB8066	Custom build for 'C:\me\botsch-kobbelt-remesher-libigl\build\CMakeFiles\12b5f038167ac11694aa035dd46fcc76\pyremesh.module.cpp.rule;C:\me\botsch-kobbelt-remesher-libigl\build\CMakeFiles\12b5f038167ac11694aa035dd46fcc76\bindings.out.cpp.rule;C:\me\botsch-kobbelt-remesher-libigl\CMakeLists.txt' exited with code 9009.	pyremesh	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets	242
Error	LNK1181	cannot open input file 'Release\remesh.lib'	remeshmesh	C:\Users\jalucas\src\meshopt\ext\botsch-kobbelt-remesher-libigl\build\LINK	1

FWIW, I wasn't expecting it to build on windows but I got pretty close so I thought I'd share the error in case it is an easy fix.

Using igl::read_triangle_mesh and igl::write_triangle_mesh would support more file formats

If you switch igl::readOBJ and igl::writeOBJ to igl::read_triangle_mesh and igl::write_triangle_mesh then this remesher could read in .ply, .off, .wrl and other file formats.

botsch-kobbelt-remesher-libigl/remeshmesh.cpp

Line 32 in 520c7d9

igl::readOBJ(in,V,F);

Installation problem related to numpyeigen

I have tried to install the code with CMake, but when I run cmake .., I get the following error message:

CMake Error at CMakeLists.txt:23 (include):
  include could not find load file:

    numpyeigen

CMake Error at CMakeLists.txt:52 (npe_add_module):
  Unknown CMake command "npe_add_module".

-- Configuring incomplete, errors occurred!

I have installed Egein3 by downloading the code and running the following code:

mkdir build
cd build
cmake ..
make
sudo make install 

Does this method implement projection onto the input surface?

If I run:

./precompiled/osx/bin/remeshmesh ~/Dropbox/models/wooden-chair-solid.obj bar.obj -i 3 -h 0.1

on this simple chair model
wooden-chair-solid.obj.zip

the output is very smoothed and most new vertices are not lying on the original geometry:

Use -O3 instead of -O

In your clang++ command in the README.md, I would recommend -O3 over -O for further compiler optimizations.

Segmentation fault (core dumped)

I receive segmentation fault when I invoke python binding.
I followed the installation instructions provided in the repository.

remeshing while keep pre-defined vertex set

Hi Silvia,

finally I've looked into the decimate function in libigl to remesh a high resolution mesh while preserving a given set of vertices. However after reading into it (https://github.com/libigl/libigl/blob/main/include/igl/decimate.h), it sounds to me that the lambda cost_and_placement is defined per edge, rather per vertex as wished. Thus it doesn't offer a direct control over the to-be-preserved vertices.

Alternatively, the function remeshmesh_mex(V,F,h,iterations,fixed_indeces) seems to do the job, with fixed_indeces defines the vertex set to keep. Will the implementation be wrapped up any time soon?

many thanks in advance,
Maolin

Difficult case: distant vertices get connected, duplicate vertices and degenerate faces

This is a difficult case and I'm impressed this remesher works as well as it does.

The input is this ugly upsampled mesh of a chair
wooden-chair-solid-subd.obj.zip

 meshstatistics wooden-chair-solid-subd.obj

outputs:

filename     /Users/ajx/Dropbox/models/wooden-chair-solid-subd.obj
number of edges                                             243456
number of faces                                             162304
number of vertices                                           81130
number of dimensions                                             3
bounding box diagonal                                      36.4748
minimum angle                                          2.10734e-08
maximum angle                                              3.09774
minimum area                                           1.97196e-10
maximum area                                              0.371565
volume                                                     683.352
centroid_x                                             1.29466e-09
centroid_y                                                  13.587
centroid_z                                                -4.00394
number of small triangles                                    26112
number of small angles                                       52992
number of close vertices                                       256
number of connected components                                   1
number of unreferenced vertices                                  0
number of handles                                               12
Euler characteristic                                           -22
number of boundary loops                                         0
number of boundary edges                                         0
number of nonmanifold edges                                      0
number of conflictedly oriented edges                            0
number of duplicate vertices                                     0
number of combinatorially duplicate faces                        0
number of geometrically degenerate faces                         0
number of combinatorially degenerate faces                       0
number of intra-component self-intersecting pairs                0
number of self-intersecting pairs                                0

So at least at a superficial level this should be valid input.

Here's the output of:

./precompiled/osx/bin/remeshmesh ~/Dropbox/models/wooden-chair-solid-subd.obj foo.obj -i 5 -h 0.1

The remeshing looks great in most areas, but there's a strange connection from the top of the chair to the base.

If I run

meshstatistics foo.obj

I also see some degeneracy issues:

filename                                                   foo.obj
number of edges                                             661251
number of faces                                             440834
number of vertices                                          220395
number of dimensions                                             3
bounding box diagonal                                       36.457
minimum angle                                                    0
maximum angle                                              3.14012
minimum area                                                     0
maximum area                                               1.39595
volume                                                     682.197
centroid_x                                             0.000766522
centroid_y                                                 13.5873
centroid_z                                                -4.00328
number of small triangles                                     3172
number of small angles                                        1098
number of close vertices                                        56
number of connected components                                   1
number of unreferenced vertices                                  0
number of handles                                               12
Euler characteristic                                           -22
number of boundary loops                                         0
number of boundary edges                                         0
number of nonmanifold edges                                      0
number of conflictedly oriented edges                            0
number of duplicate vertices                                    56
number of combinatorially duplicate faces                        0
number of geometrically degenerate faces                        86
number of combinatorially degenerate faces                       0
number of intra-component self-intersecting pairs             4017
number of self-intersecting pairs                             4017

split and collapse steps operate on different domains

Hi, thanks for this repo !

According to the paper, during a single iteration, every edge that meets a certain lower bound is split, and every edge that meets a certrain upper bound is collapsed.

It seems like in this implementation, the collapse step operates on the mesh after it has been split, rather than on the input of the iteration, which would yield a different result than the original paper where selected edges that meet the upper bound are considered prior to splitting (i.e. there could be edges that were newly created, that are considered for collapsing, and edges that should have been selected for collapsing, but aren't because their length got shortened by some split).

Is this by design? or an error?

if error, is it possible to ask you document the inputs to the split step? I noticed there is a map between old and new edges, which could potentially be used to resolve this (which I will happily submit a pull request for)