OpenMesh issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues2021-01-29T11:08:24Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/76Is that save?2021-01-29T11:08:24ZJan Möbiusmoebius@cs.rwth-aachen.deIs that save?src/OpenMesh/Tools/Subdivider/Uniform/ModifiedButterFlyT.hh
In
https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/commit/9ae08da59341e983068cb9a64572d307a7b4b730
You changed the iterators to range based. Is that really save w...src/OpenMesh/Tools/Subdivider/Uniform/ModifiedButterFlyT.hh
In
https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/commit/9ae08da59341e983068cb9a64572d307a7b4b730
You changed the iterators to range based. Is that really save while adding Edges / Faces to the underlying vector?Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/74Eigen3 Finder not included anymore and no global finder available2021-01-15T14:30:32ZJan Möbiusmoebius@cs.rwth-aachen.deEigen3 Finder not included anymore and no global finder availableMartin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/73Bug in PropertyT<bool> restore function2021-01-25T14:58:48ZJan Möbiusmoebius@cs.rwth-aachen.deBug in PropertyT<bool> restore functionI stumbled across a pretty infuriating bug in OpenMesh 8.0 (I think it still might exist
in 8.1) in the `restore` function for `PropertyT<bool>` (`Property.hh`) (though this
issue may exist elsewhere quite possibly...).
The issue occurs...I stumbled across a pretty infuriating bug in OpenMesh 8.0 (I think it still might exist
in 8.1) in the `restore` function for `PropertyT<bool>` (`Property.hh`) (though this
issue may exist elsewhere quite possibly...).
The issue occurs at the beginning of the for loop where the bit packing happens (around
line 313). The problematic statement is `_istr >> bits;`
The problem is `std::istream` by default skips white space characters
(https://en.cppreference.com/w/cpp/io/manip/skipws), so if one of the bytes in the stream
being restored happens to be 0x20 (32 - 'space' character), it will be skipped,
leading to the stream getting out of sync with the bytes read (I was able to track this
down using lots of `_is.tellg();` calls).
I've made a minimal change in Property.hh to ensure white space characters aren't
skipped: `_istr >> std::noskipws;` right before the for loop. There might be a
better more central place to enable this setting but it resolves the bug for us for now.
If anyone has any feedback on the best place for this fix I'd love to know!Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/72Eigen tests fail to compile on Linux with Eigen 3.3.72020-04-20T05:58:58ZMartin HeistermannEigen tests fail to compile on Linux with Eigen 3.3.7With both clang 9.0.1-10 and g++ 9.3.0, and Eigen 3.3.7 on Debian Testing, the eigen related unit tests fail to compile.
CI on Linux apparently currently has no Eigen, so this is not tested.
Compile output:
Clang:
```
/usr/lib/ccache/cl...With both clang 9.0.1-10 and g++ 9.3.0, and Eigen 3.3.7 on Debian Testing, the eigen related unit tests fail to compile.
CI on Linux apparently currently has no Eigen, so this is not tested.
Compile output:
Clang:
```
/usr/lib/ccache/clang++ -DENABLE_EIGEN3_TEST -DINCLUDE_TEMPLATES -DTEST_DOUBLE_TRAITS -I../src/Unittests/.. -I../src/Unittests -I/usr/include/eigen3 -I../src/OpenMesh/Core/../.. -I../src/OpenMesh/Tools/../.. -O3 -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wextra -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-variadic-macros -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wextra -Wno-non-virtual-dtor -Wno-unused-parameter -Wno-variadic-macros -DNDEBUG -g -pedantic -Wno-long-long -std=gnu++11 -MD -MT src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -MF src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o.d -o src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -c ../src/Unittests/unittests_eigen3_type.cc
../src/Unittests/unittests_eigen3_type.cc:98:3: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
../src/Unittests/unittests_eigen3_type.cc:104:3: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: calling a protected constructor of class 'Eigen::MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >'
return x;
^
../src/Unittests/unittests_eigen3_type.cc:98:3: note: in instantiation of function template specialization 'Eigen::normalize<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' requested here
normalize(normal);
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:467:36: note: declared protected here
EIGEN_DEFAULT_COPY_CONSTRUCTOR(MatrixBase)
^
In file included from ../src/Unittests/unittests_eigen3_type.cc:5:
In file included from ../src/Unittests/../Unittests/unittests_common.hh:7:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/TriMesh_ArrayKernelT.hh:64:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/TriMeshT.hh:60:
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT.hh:663:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:407:12: error: temporary of type 'MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >' has protected destructor
return normalize(n);
^
../src/Unittests/unittests_eigen3_type.cc:28:7: note: in instantiation of member function 'OpenMesh::PolyMeshT<OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity> >::calc_halfedge_normal' requested here
class OpenMeshEigenTest : public testing::Test {
^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: declared protected here
EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: expanded from macro 'EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR'
EIGEN_DEVICE_FUNC ~Derived() = default;
^
4 errors generated.
```
GCC:
```
/usr/lib/ccache/c++ -DENABLE_EIGEN3_TEST -DINCLUDE_TEMPLATES -DTEST_DOUBLE_TRAITS -I../src/Unittests/.. -I../src/Unittests -I/usr/include/eigen3 -I../src/OpenMesh/Core/../.. -I../src/OpenMesh/Tools/../.. -O3 -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wno-unused -Wextra -Wno-variadic-macros -DNDEBUG -DINCLUDE_TEMPLATES -W -Wall -Wno-unused -Wextra -Wno-variadic-macros -DNDEBUG -g -pedantic -Wno-long-long -std=gnu++11 -MD -MT src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -MF src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o.d -o src/Unittests/CMakeFiles/unittests_doublevec.dir/unittests_eigen3_type.cc.o -c ../src/Unittests/unittests_eigen3_type.cc
../src/Unittests/unittests_eigen3_type.cc: In member function ‘virtual void {anonymous}::OpenMeshEigenTest_Test_external_normalize_Test::TestBody()’:
../src/Unittests/unittests_eigen3_type.cc:98:19: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
98 | normalize(normal);
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/Unittests/unittests_eigen3_type.cc:104:19: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
104 | normalize(normal);
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh: In instantiation of ‘Eigen::MatrixBase<Derived> Eigen::normalize(Eigen::MatrixBase<Derived>&) [with Derived = Eigen::Matrix<double, 3, 1>]’:
../src/Unittests/unittests_eigen3_type.cc:98:19: required from here
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: ‘constexpr Eigen::MatrixBase<Derived>::MatrixBase(const Eigen::MatrixBase<Derived>&) [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
93 | return x;
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:467:36: note: declared protected here
467 | EIGEN_DEFAULT_COPY_CONSTRUCTOR(MatrixBase)
| ^~~~~~~~~~
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:844:65: note: in definition of macro ‘EIGEN_DEFAULT_COPY_CONSTRUCTOR’
844 | #define EIGEN_DEFAULT_COPY_CONSTRUCTOR(CLASS) EIGEN_DEVICE_FUNC CLASS(const CLASS&) = default;
| ^~~~~
In file included from ../src/Unittests/unittests_eigen3_type.cc:14:
../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:93:14: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
93 | return x;
| ^
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT.hh:663,
from ../src/Unittests/../OpenMesh/Core/Mesh/TriMeshT.hh:60,
from ../src/Unittests/../OpenMesh/Core/Mesh/TriMesh_ArrayKernelT.hh:64,
from ../src/Unittests/../Unittests/unittests_common.hh:7,
from ../src/Unittests/unittests_eigen3_type.cc:5:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh: In instantiation of ‘OpenMesh::PolyMeshT<Kernel>::Normal OpenMesh::PolyMeshT<Kernel>::calc_halfedge_normal(OpenMesh::PolyMeshT<Kernel>::HalfedgeHandle, double) const [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>; OpenMesh::PolyMeshT<Kernel>::Normal = Eigen::Matrix<double, 3, 1>; OpenMesh::PolyMeshT<Kernel>::HalfedgeHandle = OpenMesh::HalfedgeHandle]’:
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:355:29: required from ‘void OpenMesh::PolyMeshT<Kernel>::update_halfedge_normals(double) [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>]’
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:324:41: required from ‘void OpenMesh::PolyMeshT<Kernel>::update_normals() [with Kernel = OpenMesh::AttribKernelT<OpenMesh::FinalMeshItemsT<EigenTraits, true>, OpenMesh::TriConnectivity>]’
../src/Unittests/unittests_eigen3_type.cc:235:25: required from here
../src/Unittests/../OpenMesh/Core/Mesh/PolyMeshT_impl.hh:407:21: error: ‘Eigen::MatrixBase<Derived>::~MatrixBase() [with Derived = Eigen::Matrix<double, 3, 1>]’ is protected within this context
407 | return normalize(n);
| ~~~~~~~~~^~~
In file included from /usr/include/eigen3/Eigen/Core:88,
from ../src/Unittests/../OpenMesh/Core/Geometry/EigenVectorT.hh:47,
from ../src/Unittests/unittests_eigen3_type.cc:14:
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:870:23: note: declared protected here
870 | EIGEN_DEVICE_FUNC ~Derived() = default;
| ^
/usr/include/eigen3/Eigen/src/Core/MatrixBase.h:468:5: note: in expansion of macro ‘EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR’
468 | EIGEN_DEFAULT_EMPTY_CONSTRUCTOR_AND_DESTRUCTOR(MatrixBase)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/71Docu pics broken2020-03-18T08:22:32ZJan Möbiusmoebius@cs.rwth-aachen.deDocu pics brokenJan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/70Vertex Split not implemented?2020-03-17T13:13:25ZJan Möbiusmoebius@cs.rwth-aachen.deVertex Split not implemented?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/67property visualizer, edge property visualization2019-08-07T13:30:09ZNicolas Gallego-Ortizproperty visualizer, edge property visualizationSystem: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected be...System: macOS 10.14.6, c++ compiler clang-1000.11.45.5, cmake 3.14.5,
Debug mode, using Qt Creator 4.9.2
Shader: pipeline render plugin, (although changing it does not change the behavior)
Hi all,
I just observed this unexpected behavior when visualizing edge properties of meshes (OpenMesh) with the property visualization plugin. I the provided file there is a triangle mesh of a plane, and an edge property saved from it.
I get this error message on the console, and the mesh is rendered as a tube on the z-direction as shown in the image. The plane mesh can be seen after clicking on the object for a short time but the edges shown are not those of the original mesh.
I would be happy to help solve this issue, for now just let me know if you can reproduce it in other systems and some hints on where to start the debugging process.
Thanks,
Nicolas
```
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:650 - 1282
GLError /Users/nicolas.gallego-ortiz/projects/OpenFlipper-072019/OpenFlipper/libs_required/ACG/ShaderUtils/GLSLShader.cc:704 - 1282 - inColor
```
[mesh2.om](/uploads/7d19640750d0d63bac96123c433397d2/mesh2.om)
[kappa.eprop](/uploads/85cb68a117b9b3876525ecc5ce580307/kappa.eprop)
![screenshot](/uploads/086c07c3b29a4618be864f85cb6e206e/screenshot.png)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/66heap-buffer-overflow while adding an invalid triangle face2021-01-29T11:08:44ZSven-Kristofer Pilzheap-buffer-overflow while adding an invalid triangle faceI came across a pathological mesh example that triggered a heap corruption in version %"OpenMesh 8.0".
The following is a minimal failing example, which will fail when run with *AddressSanitizer* (*heap-buffer-overflow* in ` OpenMesh::P...I came across a pathological mesh example that triggered a heap corruption in version %"OpenMesh 8.0".
The following is a minimal failing example, which will fail when run with *AddressSanitizer* (*heap-buffer-overflow* in ` OpenMesh::PolyConnectivity::add_face(OpenMesh::VertexHandle const*, unsigned long)`).
```cpp
#include <OpenMesh/Core/Mesh/PolyMesh_ArrayKernelT.hh>
typedef OpenMesh::PolyMesh_ArrayKernelT<> MyMesh;
int main()
{
MyMesh mesh;
const auto a = mesh.add_vertex(MyMesh::Point{-6.95757 -0.418557 -7.25885});
const auto b = mesh.add_vertex(MyMesh::Point{-7.03569 -0.128014 -7.26395});
mesh.add_face(a,b,a);
return 0;
}
```
When run with assertions enabled, this triggers:
> OpenMesh/Core/Mesh/PolyConnectivity.cc:272: OpenMesh::ArrayKernel::FaceHandle OpenMesh::PolyConnectivity
> ::add_face(const VertexHandle*, size_t): Assertion `boundary_prev.is_valid()' failed.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/58Peristent Edge Properties2018-11-27T13:40:38ZMax Lyonlyon@cs.rwth-aachen.dePeristent Edge PropertiesThe om file format allows to store meshes together with custom properties. This does not work correctly for edge (and halfedge) properties.
The om file format stores explicitly only vertices and faces (as ordered set of vertices). When ...The om file format allows to store meshes together with custom properties. This does not work correctly for edge (and halfedge) properties.
The om file format stores explicitly only vertices and faces (as ordered set of vertices). When reading from a file, edges are created on the fly when they are needed for a face. This means that the edges in the loaded mesh may be in a different order than in the stored mesh.
Edge properties are stored and loaded in the same order. Thus, the loaded edge properties may not correspond to the edge.
I added a unittest which runs into this problem in commit 84eccff6a64a3749c0d01ff1f8a9b84d050c74cc.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/56Mention new OM python bindings in Documentation2018-12-06T08:20:56ZMartin HeistermannMention new OM python bindings in Documentationhttps://www.openmesh.org/Daily-Builds/Doc/a00036.html only describes the old python bindings, which can lead to confusion (see OM mailing list on 2016-06-08), I think we should (very visibly) refer to the new bindings there.https://www.openmesh.org/Daily-Builds/Doc/a00036.html only describes the old python bindings, which can lead to confusion (see OM mailing list on 2016-06-08), I think we should (very visibly) refer to the new bindings there.Isaak LimIsaak Limhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/55add the TriangleBSPTree to OpenMesh2018-06-05T11:48:45ZJanis Bornadd the TriangleBSPTree to OpenMeshSpatial queries on meshes seem to be a common task [(see question here)](https://stackoverflow.com/questions/50696430/find-neighbours-inside-query-in-openmesh).
ACG provides a TriangleBSPTree which seems to work well for this purpose, b...Spatial queries on meshes seem to be a common task [(see question here)](https://stackoverflow.com/questions/50696430/find-neighbours-inside-query-in-openmesh).
ACG provides a TriangleBSPTree which seems to work well for this purpose, but ACG is not bundled with OpenMesh. Should we migrate the TriangleBSPTree from ACG to OpenMesh?https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/54get_property inconsistent return value over build configs2020-04-02T07:39:21ZMatthias Möllerget_property inconsistent return value over build configsHi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(pro...Hi,
consider the following code:
```c++
Mesh mesh;
std::string = "prop";
VPropHandleT<float> prop_float;
mesh.add_property(prop_float, name);
VPropHandleT<Vec3d> prop_vec; //<-- different type
bool result = mesh.get_property_handle(prop_vec, name); //<-- request handle with wrong type
```
The output in result depends on the Build Configuration.
- In Debug mode, following holds: `result==false`
- In Release mode, following holds: `result==true`
It is because in "PropertyContainer.h", the type check is disabled in Release mode (line 126-128).
The function should return the same value over the different
build configurations.
(I would prefer the type check enabled, because it seems to be complex, checking outside of the PropertyContainer if the type of your prophandle is the correct one
__edit__ or provide an additional member-function "has_type", or something like this, skipping the dynamic_cast in get_property)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/53swap_*_indices methods2018-05-03T14:28:04ZJanis Bornswap_*_indices methodsOpenVolumeMesh provides [methods](https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/blob/master/src/OpenVolumeMesh/Core/TopologyKernel.hh#L528) to reorder the indices of mesh elements (e.g. `swap_vertex_indices`) wit...OpenVolumeMesh provides [methods](https://www.graphics.rwth-aachen.de:9000/OpenVolumeMesh/OpenVolumeMesh/blob/master/src/OpenVolumeMesh/Core/TopologyKernel.hh#L528) to reorder the indices of mesh elements (e.g. `swap_vertex_indices`) without affecting the geometry or structure of the mesh in any other way. This is quite useful for reindexing mesh data when working in matrix form in order to achieve a certain block structure.
It would be useful to have the same feature in OpenMesh.https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/52Move towards using free functions on built-in properties.2018-05-30T09:00:14ZChristian MattesMove towards using free functions on built-in properties.OpenMesh supports changing the type of the built-in properties (like the vertex position), which is a great feature.
For this to work however, the types have to implement certain methods such as `length()` and `normalize()` (as member m...OpenMesh supports changing the type of the built-in properties (like the vertex position), which is a great feature.
For this to work however, the types have to implement certain methods such as `length()` and `normalize()` (as member methods).
Replacing the calls to those methods by calls to free methods of the same name (and then implementing those free methods for the OpenMesh built-in Vectors as calls to the member) would make it easier to support new types for Points.
E.g. to use Eigen's Vector types with OpenMesh, it is currently required to use Eigen's "plugin" system, which can cause the program to fail in hard to debug ways.Christian MattesChristian Matteshttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/51split_edge Creates Non-Triangular Faces on TriMeshes2018-10-30T09:20:21ZMax Lyonlyon@cs.rwth-aachen.desplit_edge Creates Non-Triangular Faces on TriMeshes```PolyConnectivity``` implements the two methods ```split_edge(EdgeHandle, VertexHandle)``` and ```split_edge_copy(EdgeHandle, VertexHandle)``` which split an edge without splitting the incident faces, thus increasing the valence of the...```PolyConnectivity``` implements the two methods ```split_edge(EdgeHandle, VertexHandle)``` and ```split_edge_copy(EdgeHandle, VertexHandle)``` which split an edge without splitting the incident faces, thus increasing the valence of the incident faces by one.
```TriConnectivity``` implements the two similar methods ```split(EdgeHandle, VertexHandle)``` and ```split_copy(EdgeHandle, VertexHandle)``` which do split the incident faces, thus performing a 2 to 4 split (or 1 to 2 split on boundaries) as expected.
Since ```TriConnectivity``` publicly inherits from ```PolyConnectivity```, ```split_edge``` can be called on a ```TriConnectivity``` resulting in non-triangular faces.
Should we add ```split_edge``` and ```split_edge_copy``` methods to ```TriConnectivity``` which call ```split``` and ```split_edge``` to prevent this?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/50Standard Properties after Assignment2018-03-19T15:21:26ZMax Lyonlyon@cs.rwth-aachen.deStandard Properties after AssignmentIf a mesh which has standard properties is assigned a mesh which does not, the former will have no standard properties (as expected, I guess) but a positive ref count. When standard properties are than requested, they are not created due...If a mesh which has standard properties is assigned a mesh which does not, the former will have no standard properties (as expected, I guess) but a positive ref count. When standard properties are than requested, they are not created due to that positive ref count. Only for the four status properties does this work.
I added a unit test in da81dbaffa3222041c9edb42b8ad22ab38342afe for reproducibility.Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/47Binary STL Files are recogniced as ASCII2017-09-26T13:42:04ZMartin SchultzBinary STL Files are recogniced as ASCII```
[...] in the function _STLReader_::check_stl_type() (STLReader.cc file) you assume that a STL is encoded in ASCII format by looking for the keyword solid, i.e., line 476:
//check for ascii keyword solid
if(strnicmp("solid",&l...```
[...] in the function _STLReader_::check_stl_type() (STLReader.cc file) you assume that a STL is encoded in ASCII format by looking for the keyword solid, i.e., line 476:
//check for ascii keyword solid
if(strnicmp("solid",&line[firstChar],5) == 0)
{
return STLA;
}
The problem is that also some binary STL files start with the "solid" keyword, and it seems the standard allows it, at least looking at the first references I've found:
https://people.sc.fsu.edu/~jburkardt/data/stla/stla.html
https://people.sc.fsu.edu/~jburkardt/data/stlb/stlb.html
[...]
a workaround solution could be to look for the keyword "facet" in place of the keyword "solid" [...]
by Alberto Pretto
```
Related to: https://www.graphics.rwth-aachen.de:9000/OpenMesh/OpenMesh/merge_requests/83
example file to trigger this issue:
[sportellino.stl](/uploads/7a3200439fbb8bff53dad0527d10a5f0/sportellino.stl)https://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/43Cannot compile OpenMesh with unittests enabled2017-06-29T08:32:21ZMartin SchultzCannot compile OpenMesh with unittests enabledI can not compile OpenMesh with the unittests enabled on our lab machines.
I am getting compile errors from :
```
gtest-message.h:191
internal::StringStreamToString(ss_.get());
undefined reference to StringStreamToString(ss_.get());
``...I can not compile OpenMesh with the unittests enabled on our lab machines.
I am getting compile errors from :
```
gtest-message.h:191
internal::StringStreamToString(ss_.get());
undefined reference to StringStreamToString(ss_.get());
```
The default gtest library is selected by cmake as
/ACG/acgdev/gcc-4.7-x86_64/gtest/
but since the lab machines have been updated the gcc --version command states the compiler version is 6.3.0. I tried using the gtest library from /ACG/acgdev/gcc-4.9-x86_64/gtest/ but it gives the same error.
Is this caused by incompatibilities of the older gcc versions / libraries built with it?Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/42Decimater ModRoundness alway collapses2017-05-05T14:26:01ZDaniel GotzenDecimater ModRoundness alway collapsesIn ModRoundnessT.hh in line 151 and 173 the first parameter calling roundness() "vector_cast<Vec3f>(_ci.p1)" is the same than C but should be the Vertex of the second face NOT connected to the collapsed edge.In ModRoundnessT.hh in line 151 and 173 the first parameter calling roundness() "vector_cast<Vec3f>(_ci.p1)" is the same than C but should be the Vertex of the second face NOT connected to the collapsed edge.Daniel GotzenDaniel Gotzenhttps://gitlab.vci.rwth-aachen.de:9000/OpenMesh/OpenMesh/-/issues/40Creating a zero-vector with "ACG::Vec3d(0)" compiles (and behaves as expected...2019-01-15T15:13:18ZKersten SchusterCreating a zero-vector with "ACG::Vec3d(0)" compiles (and behaves as expected) for GCC, but not for MSVC (2013)One could argue about whether GCC or MSVC does 'the right thing'. However, I would like them to behave similarly.
Below you find the inexpressive MSVC compile error message.
MSVC (2013) Compiler:
error C2440: '<function-style-cast>' : c...One could argue about whether GCC or MSVC does 'the right thing'. However, I would like them to behave similarly.
Below you find the inexpressive MSVC compile error message.
MSVC (2013) Compiler:
error C2440: '<function-style-cast>' : cannot convert from 'int' to 'ACG::Vec3d'
No constructor could take the source type, or constructor overload resolution was ambiguousJanis BornJanis Born