OpenFlipper-Free issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues2024-02-05T12:34:09Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/186Build issue: System-wide install of pybind11 interferes2024-02-05T12:34:09ZMartin HeistermannBuild issue: System-wide install of pybind11 interferesHi, my system has pybind11 installed in a global include dir, which apparently takes precedence over the local copy of pybind11.
It leads to this sort of compile error:
```
[...]
In file included from /Users/mh/src/OpenFlipper-IGM/OpenFl...Hi, my system has pybind11 installed in a global include dir, which apparently takes precedence over the local copy of pybind11.
It leads to this sort of compile error:
```
[...]
In file included from /Users/mh/src/OpenFlipper-IGM/OpenFlipper/PythonInterpreter/PyLogHook.h:32:
In file included from /opt/homebrew/include/pybind11/pybind11.h:13:
[...]
In file included from /opt/homebrew/include/pybind11/detail/../attr.h:13:
/opt/homebrew/include/pybind11/detail/common.h:479:16: error: redefinition of 'ssize_t_cast'
inline ssize_t ssize_t_cast(const IntType &val) {
^
/Users/mh/src/OpenFlipper-IGM/OpenFlipper/libs_required/ACG/../pybind11/include/pybind11/detail/common.h:483:16: note: previous definition is here
inline ssize_t ssize_t_cast(const IntType &val) {
```
## Why does it happen - include folder precedence
At least with gcc and clang, the specified include dirs have left-to-right preference, i.e., earlier has precedence.
The corresponding commandline includes ` -isystem /opt/homebrew/include `, and later `-isystem /Users/mh/src/OpenFlipper-IGM/OpenFlipper/libs_required/pybind11/include`. Folders specified by `-I` take precedence, which is probably what we would like to use for the vendored copy of pybind11.
The cause for CMake to use `-i system` instead of `-I` is the combination of
```
# Check if pybind11 is being used directly or via add_subdirectory
if(CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR)
[...]
else()
set(PYBIND11_MASTER_PROJECT OFF)
set(pybind11_system SYSTEM)
endif()
```
and
```
target_include_directories(
pybind11_headers ${pybind11_system} INTERFACE $<BUILD_INTERFACE:${pybind11_INCLUDE_DIR}>
```
in `OpenFlipper/libs_required/pybind11/CMakeLists.txt`.
## Fix?
Patching that file to just `set(pybind11_system "")` results in a successful build for me, but I'm not certain this is the best kind of fix.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/185Feature edge rendering broken in colored-edges rendering2023-03-17T09:15:30ZMartin HeistermannFeature edge rendering broken in colored-edges renderingWhen visualizing an edge property using edge colors on a mesh that also has feature edges, feature edges are drawn randomly across the space, not even along mesh edges. Every time I click "Visualize" in propvis, the random mess changes, ...When visualizing an edge property using edge colors on a mesh that also has feature edges, feature edges are drawn randomly across the space, not even along mesh edges. Every time I click "Visualize" in propvis, the random mess changes, so I'd guess uninitialized memory - however once in a blue moon, I actually get a rendering that looks like I would expect.
![bad](/uploads/166aacb87d04eada58431db4315b4544/fail.png)
![good](/uploads/c281f02da8ab6c9eba05339210aff37a/ok.png)
Btw, a while ago, I had fixed (or maybe not entirely fixed :/) some bug with similar symptoms, I wouldn't be surprised if this is in similar code paths:
https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper/-/merge_requests/188Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/182File loading race condition leads to crashes2022-05-25T14:13:01ZMartin HeistermannFile loading race condition leads to crashes[Update 2022-05-25: added more details to clarify the race]
1. A file loading operation calls the plugins's `load()` function called in a new thread
1. `load()` uses `addEmptyObject()` is used to create an object to hold the loaded file...[Update 2022-05-25: added more details to clarify the race]
1. A file loading operation calls the plugins's `load()` function called in a new thread
1. `load()` uses `addEmptyObject()` is used to create an object to hold the loaded file.
1. This emits the `emptyObjectAdded` signal, which is connected to `Core::slotEmptyObjectAdded`
1. `Core::slotEmptyObjectAdded` emits `signalObjectUpdated(_id)` and `signalObjectUpdated(_id, UPDATE_ALL)`
Now these two things can happen in parallel:
- In the loading thread, file loading (e.g. OM or OVM) occurs
- Other plugins get notified vis `slotObjectUpdated` and can operate on this unfinished object at the same time
In particular, `PropertyVisPlugin::slotObjectUpdated` does cause crashes for me, but likely is not the only problematic plugin.
With OM, this can lead to a crash while properties are loaded from the file with the following order of execution:
- Main thread, propvis' `OMPropertyModel<...>::gatherProperties()` calls `mesh_->fprops_begin()`
- File load thread: `OpenMesh::PropertyCreator::create_property()`, this invalidates the fprops_begin iterator
- Main thread: The Property iterator is dereferenced -> crash
I attached the output of an ASAN instrumented build that runs into this with detailed backtraces:
[of-load-om-race-condition-asan-output.txt](/uploads/1621a94f55aea9a81e8dab0596e5bc21/of-load-om-race-condition-asan-output.txt)
How should we go about solving this? Maybe just putting a mutex around mesh access from objects? This would also prevent similar issues when performing mesh processing in a worker thread.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/174Uniform Remeshing produces degenerate patches using vertex selection2021-09-07T10:08:05ZZain SelmanUniform Remeshing produces degenerate patches using vertex selectionWhen using the Remesher Plugin (Uniform) on a simple mesh (cube1.off) the remesher produces broken patches.
Steps to reproduce:
- Open the cube1.off in `/path/to/OpenFlipper-Free/OpenFlipper/`
- Select a large proportion of a side of the...When using the Remesher Plugin (Uniform) on a simple mesh (cube1.off) the remesher produces broken patches.
Steps to reproduce:
- Open the cube1.off in `/path/to/OpenFlipper-Free/OpenFlipper/`
- Select a large proportion of a side of the cube
![cube1](/uploads/1d548a7445a3a352eb37bec779754220/cube1.png)
- Set the edge length (0.02 here)
![cube2](/uploads/bae851765546d0efdf239759b4813d37/cube2.png)
- Remesh
![cube3](/uploads/c6732e3c195e6a84c5ead22456f6f3e2/cube3.png)
- Close up of degenerate path
![cube4](/uploads/852e034c57c253475f7e6ac2b91e335e/cube4.png)
If you compare the result to the input and edge length of 0.02 is not too small compared to the average. Starting with a value of 0.025 and then choosing 0.02 also results in this kind of behavior.Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/175Bad remesh and .stl export2021-09-07T10:07:57ZValentin NigolianBad remesh and .stl exportConcerns the master branch.
Remeshing the attached file with the Uniform Remesher results in a bad .stl export.
I used the "Estimate Parameters" button to get the remeshing parameters.
All faces were selected
[octopus-2.stl](/uploa...Concerns the master branch.
Remeshing the attached file with the Uniform Remesher results in a bad .stl export.
I used the "Estimate Parameters" button to get the remeshing parameters.
All faces were selected
[octopus-2.stl](/uploads/491cbabf39a6d5f4bfad584d62a2be2c/octopus-2.stl)Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/180Panning broken when zooming in?2021-09-07T10:07:48ZJan Möbiusmoebius@cs.rwth-aachen.dePanning broken when zooming in?In V4.1 (Windows), panning the view by holding the middle mouse/scroll
wheel no longer works after double-clicking on a mesh to change the
center of rotation. Panning works before double-clicking. This is a
regression from V4.0 (Windows)...In V4.1 (Windows), panning the view by holding the middle mouse/scroll
wheel no longer works after double-clicking on a mesh to change the
center of rotation. Panning works before double-clicking. This is a
regression from V4.0 (Windows).
I looked at this behavior more and have a correction and clarification.
The behavior is the same in 4.0 and 4.1. The pan behavior appears to be
scaled by the zoom level, so after double-clicking to focus/zoom a
couple times, the pan scaling is effectively zero. That is the realJan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/135HiDPI Support on macOS2021-02-02T11:30:47ZMartin HeistermannHiDPI Support on macOSOn OSX with a HiDPI screen, OpenFlipper appears to be rendered at a low resolution and is then scaled up, resulting in a very pixelated look.
I believe this is the effect of the _magnified mode_ documented here:
https://developer.apple....On OSX with a HiDPI screen, OpenFlipper appears to be rendered at a low resolution and is then scaled up, resulting in a very pixelated look.
I believe this is the effect of the _magnified mode_ documented here:
https://developer.apple.com/library/content/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html
Setting the plist entries for HiDPI support fixes this, however the OpenGL viewport is rendered at a quarter of the intended size.
I played around with the Qt enviroment variables documented at http://doc.qt.io/qt-5/highdpi.html , QT_SCALE_FACTOR=0.5 yields the correct OpenGL viewport size, at the cost of extremely tiny fonts everywhere.
My system is a 2017 13" MacBook Pro running High Sierra.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/169Infinite loop in DrawMeshT when deleted elements are present2020-02-14T10:29:50ZMax Lyonlyon@cs.rwth-aachen.deInfinite loop in DrawMeshT when deleted elements are presentCode to reproduce:
```
int id;
emit addEmptyObject( DATA_TRIANGLE_MESH, id);
auto& mesh = *PluginFunctions::triMesh(id);
mesh.add_vertex(TriMesh::Point(0,0,0));
mesh.add_vertex(TriMesh::Point(1,0,0));
mesh.add_vertex(TriMes...Code to reproduce:
```
int id;
emit addEmptyObject( DATA_TRIANGLE_MESH, id);
auto& mesh = *PluginFunctions::triMesh(id);
mesh.add_vertex(TriMesh::Point(0,0,0));
mesh.add_vertex(TriMesh::Point(1,0,0));
mesh.add_vertex(TriMesh::Point(0,1,0));
mesh.add_vertex(TriMesh::Point(1,1,0));
mesh.add_face(OpenMesh::VertexHandle(0), OpenMesh::VertexHandle(1), OpenMesh::VertexHandle(2));
mesh.add_face(OpenMesh::VertexHandle(1), OpenMesh::VertexHandle(3), OpenMesh::VertexHandle(2));
mesh.delete_face(OpenMesh::FaceHandle(0));
```https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/163Docs: Example Plugins should be tested by CI2019-03-07T20:35:09ZMartin HeistermannDocs: Example Plugins should be tested by CIThe example plugins were broken for various reasons for a long time.
I suggest integrating them into CI so this won't happen again.
Maybe a PluginCollection-Examples that is disabled by default?The example plugins were broken for various reasons for a long time.
I suggest integrating them into CI so this won't happen again.
Maybe a PluginCollection-Examples that is disabled by default?https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/162ShaderPipeline does not show colored halfedges2019-02-08T14:32:15ZMax Lyonlyon@cs.rwth-aachen.deShaderPipeline does not show colored halfedgesUsing draw mode Halfedges Colored, halfedges of an OpenMesh mesh are rendered with their specular color instead of the specified per halfedge color.Using draw mode Halfedges Colored, halfedges of an OpenMesh mesh are rendered with their specular color instead of the specified per halfedge color.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/158Show halfedge selection for Volume meshes2018-06-13T18:00:52ZMartin HeistermannShow halfedge selection for Volume meshesI can select halfedges using the scripting interface, but don't see them colored when using the halfedge drawmode.I can select halfedges using the scripting interface, but don't see them colored when using the halfedge drawmode.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/116Cleanup assimp plugin and add to Free branch2018-06-05T11:40:49ZJan Möbiusmoebius@cs.rwth-aachen.deCleanup assimp plugin and add to Free branchOpenFlipper-4.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/151VolumeMeshPicking Sausage and Cheese2018-05-15T08:12:09ZMartin SchultzVolumeMeshPicking Sausage and CheeseThe Sausage and Cheese selection operators seem to cause errors in OpenFlipper.
After selecting the sausage or cheese operator, and trying to pick into a volume mesh, the Toolbar icons do not work anymore.The Sausage and Cheese selection operators seem to cause errors in OpenFlipper.
After selecting the sausage or cheese operator, and trying to pick into a volume mesh, the Toolbar icons do not work anymore.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/154Using Volume Vertex picking on a TriMesh freezes the whole GUI2018-05-15T08:12:09ZMartin HeistermannUsing Volume Vertex picking on a TriMesh freezes the whole GUIAccidentally trying to pick a vertex of a trimesh using the volume vertex selection correctly prints an error message, then the whole GUI does not react to any input anymore.
Possibly related to #151?
Tested on MacOS with CoreProfile r...Accidentally trying to pick a vertex of a trimesh using the volume vertex selection correctly prints an error message, then the whole GUI does not react to any input anymore.
Possibly related to #151?
Tested on MacOS with CoreProfile rendering.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/134Outdated OSX/MacOS Build Documentation2018-02-22T11:38:55ZMartin HeistermannOutdated OSX/MacOS Build DocumentationIt still references qt4 and svn.It still references qt4 and svn.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/129windows coreprofile embedded logger is not working2017-09-20T10:22:26ZMartin Schultzwindows coreprofile embedded logger is not workingwhen a coreprofile is used on windows, the logger cannot be used as embedded into gl.
as a workaround i disabled the setting by returning normal logger mode when windows is used, a core profile is requested and the logger was set to embe...when a coreprofile is used on windows, the logger cannot be used as embedded into gl.
as a workaround i disabled the setting by returning normal logger mode when windows is used, a core profile is requested and the logger was set to embedded. You might have to pull the logger up in that case.
The problem is caused by drawing the logger using the QPainter, which works perfectly fine on linux and osx, but on windows a glerror is caused.
once this is fixed, the workaround can be removed
affected code is GlobalOptions.cc ll:605-610 git commit hash 6826cda2db45f93d0d7959d1eb998f005abef4c8 of OpenFlipper submodule
```
// workaround for windows issue with drawing logger in scene using coreProfile (thank you Qt)
#ifdef WIN32
if(coreProfile_ && state == LoggerState::InScene)
return LoggerState::Normal;
#endif
/////////////////////////////////////////////////////////////////////////////////////////////
```https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/11Texturecontrol reuse uploaded textures (e.g. Environment maps)2017-07-26T08:09:50ZJan Möbiusmoebius@cs.rwth-aachen.deTexturecontrol reuse uploaded textures (e.g. Environment maps)OpenFlipper 3.1Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/16OBJ Reader / Writer optimization2017-07-26T08:09:50ZMartin SchultzOBJ Reader / Writer optimizationsince the obj reader performance has already been improved, the writer performance and material reading should be looked into.since the obj reader performance has already been improved, the writer performance and material reading should be looked into.Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/29After changing texture coordinates, screen update takes very long2017-07-26T08:09:32ZHans-Christian EbkeAfter changing texture coordinates, screen update takes very longI have a mesh with 10M triangles and per-halfedge texture coordinates. When I change the texture coordinates, OpenFlipper blocks four several seconds before showing the updated texture. This process should be sped up.I have a mesh with 10M triangles and per-halfedge texture coordinates. When I change the texture coordinates, OpenFlipper blocks four several seconds before showing the updated texture. This process should be sped up.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/39Interface for rendering with custom properties2017-07-26T08:09:32ZChristopher TenterInterface for rendering with custom properties- analyze vertex shader for required attributes
- take that attribute name and add it to the vbo
- priority of the property source if name is ambiguous:
halfedge > vertex > face > model
- figure out a way to integrate this w...- analyze vertex shader for required attributes
- take that attribute name and add it to the vbo
- priority of the property source if name is ambiguous:
halfedge > vertex > face > model
- figure out a way to integrate this with least overhead for all nodes..