OpenFlipper-Free issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues2017-04-20T10:23:35Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/95Windows does not execute plugin unittests2017-04-20T10:23:35ZJan Möbiusmoebius@cs.rwth-aachen.deWindows does not execute plugin unittestsOpenFlipper-4.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/94OpenFlipper debug build does not run with gdb2017-05-08T15:04:45ZChristopher TenterOpenFlipper debug build does not run with gdbgdb reports an internal error when OpenFlipper loads the plugins and then terminates.
This happens with the current master branch.
gdb reports an internal error when OpenFlipper loads the plugins and then terminates.
This happens with the current master branch.
https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/93Investigae CMAKE performance2017-05-23T13:15:04ZMartin SchultzInvestigae CMAKE performanceCMAKE has become quite slow. investigate possible performance issues by means of profiling and analysis of the cmake code.CMAKE has become quite slow. investigate possible performance issues by means of profiling and analysis of the cmake code.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/92Write unittest for Merge plugin2020-04-23T09:47:48ZMartin SchultzWrite unittest for Merge pluginit seems like the merge plugin is not copying the properties in the merge process as intended.
Investigate and fix this, s.t. at least standard properties are copied.
In addition to that write a unittest to check if properties are copied...it seems like the merge plugin is not copying the properties in the merge process as intended.
Investigate and fix this, s.t. at least standard properties are copied.
In addition to that write a unittest to check if properties are copied as intended.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/91Deselection of Global Draw Mode when shift-clicking other Draw Mode2017-05-04T14:40:30ZPeter CollienneDeselection of Global Draw Mode when shift-clicking other Draw ModeExample:
The global Draw Mode is set to "solid (colored per face)". Whenever i shift-click on wireframe to also see the wireframe, the global draw mode is deselected and all i see is a wireframe.
Desired Behaviour: Keep the previous glob...Example:
The global Draw Mode is set to "solid (colored per face)". Whenever i shift-click on wireframe to also see the wireframe, the global draw mode is deselected and all i see is a wireframe.
Desired Behaviour: Keep the previous global draw mode and additionaly render using the selected draw mode when shift-clicking a different draw modeOpenFlipper-4.0Jascha WedowskiJascha Wedowskihttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/90Updates to OpenVolumemesh cause problems in OpenFlippe2017-05-04T12:33:24ZJan Möbiusmoebius@cs.rwth-aachen.deUpdates to OpenVolumemesh cause problems in OpenFlippeBranch is Update_OVMBranch is Update_OVMOpenFlipper-4.0Max Lyonlyon@cs.rwth-aachen.deMax Lyonlyon@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/89meshConversion fails when converting to polyMesh2017-05-04T12:33:24ZMartin SchultzmeshConversion fails when converting to polyMeshthe scripted code returns always -1 when a mesh is converted to polymesh.
seems to be a type of line 139 where a local copy of the variable newID is used.the scripted code returns always -1 when a mesh is converted to polymesh.
seems to be a type of line 139 where a local copy of the variable newID is used.Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/88OpenFlipper needs resize to work2017-05-04T12:33:24ZMartin SchultzOpenFlipper needs resize to workWhen i start openflipper, the opengl canvas remains black no matter what i do.
Only after i resized the window, the opengl canvas gets updated and from then on works as expected.
I don't think the application should behave this way a...When i start openflipper, the opengl canvas remains black no matter what i do.
Only after i resized the window, the opengl canvas gets updated and from then on works as expected.
I don't think the application should behave this way after startup.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/87Plugin MeshConvert cppcheck2017-05-04T12:33:24ZJan Möbiusmoebius@cs.rwth-aachen.dePlugin MeshConvert cppcheckPlugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::toolbar' is not initialized in the constructor.
[Plugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::grp' is not init...Plugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::toolbar' is not initialized in the constructor.
[Plugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::grp' is not initialized in the constructor.
[Plugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::bidirectionalConversion' is not initialized in the constructor.
[Plugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::polyConversion' is not initialized in the constructor.
[Plugin-MeshConvert/MeshConvert.cc:104]: (warning) Member variable 'MeshConvertPlugin::triConversion' is not initialized in the constructor.OpenFlipper-4.0Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/86Sort out the defines in the OpenVolumemesh plugins2017-05-04T12:33:24ZJan Möbiusmoebius@cs.rwth-aachen.deSort out the defines in the OpenVolumemesh pluginsThe types define ENABLE_POLYHEDRALMESH_SUPPORT
while the plugins curreently seem to use -DENABLE_OPENVOLUMEMESH_SUPPORT -DENABLE_OPENVOLUMEMESH_POLYHEDRAL_SUPPORTThe types define ENABLE_POLYHEDRALMESH_SUPPORT
while the plugins curreently seem to use -DENABLE_OPENVOLUMEMESH_SUPPORT -DENABLE_OPENVOLUMEMESH_POLYHEDRAL_SUPPORTOpenFlipper-4.0Jan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/85Removed workaround2017-05-04T12:33:24ZJan Möbiusmoebius@cs.rwth-aachen.deRemoved workaroundThe workaround for qt creator has been removed and replaced by a cmake internal command.
Please check if it works.The workaround for qt creator has been removed and replaced by a cmake internal command.
Please check if it works.OpenFlipper-4.0Martin HeistermannMartin Heistermannhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/84BSPImplT (OMTriangleBSP) fails on small meshes.2017-05-04T12:33:24ZHans-Christian EbkeBSPImplT (OMTriangleBSP) fails on small meshes.The BSPImplT, the foundation for anything space partitioning related, all ray intersection stuff, all projection stuff, etc. fails on really small meshes. It doesn't find any ray collisions.The BSPImplT, the foundation for anything space partitioning related, all ray intersection stuff, all projection stuff, etc. fails on really small meshes. It doesn't find any ray collisions.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/83Visualization mode "Solid (face textured)" not available after loading obj w...2017-05-04T12:33:24ZMax Lyonlyon@cs.rwth-aachen.deVisualization mode "Solid (face textured)" not available after loading obj with halfedge texcoords.When loading the attached [box.obj](/uploads/989ca6d0927e700ba6850ee76985314f/box.obj) the halfedge_texcoord2D property is correctly filled with the data from the file. However, when choosing a visualization mode for the mesh, only "Soli...When loading the attached [box.obj](/uploads/989ca6d0927e700ba6850ee76985314f/box.obj) the halfedge_texcoord2D property is correctly filled with the data from the file. However, when choosing a visualization mode for the mesh, only "Solid (textured)" (using vertex texcoords) is available, "Solid (face textured)" (using halfedge texcoords) is not.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/82Draw mode "Solid (colored per vertex, shaded)" actually shows colors per face2017-05-04T12:33:24ZPatrick SchmidtDraw mode "Solid (colored per vertex, shaded)" actually shows colors per faceAfter assigning a color to each vertex and switching to the draw mode "Solid (colored per vertex, shaded)", I see the following:
![per_vertex_shaded](/uploads/04b7915038f5bad44bad7a8e8a3ad37c/per_vertex_shaded.png)
Instead of linearl...After assigning a color to each vertex and switching to the draw mode "Solid (colored per vertex, shaded)", I see the following:
![per_vertex_shaded](/uploads/04b7915038f5bad44bad7a8e8a3ad37c/per_vertex_shaded.png)
Instead of linearly interpolating the vertex colors, constant colors are shown per face.
The non-shaded draw mode "Solid (colored per vertex)" works just fine:
(Exact same colors are used)
![per_vertex](/uploads/48b445750eb49a2a1e2067e244eb862b/per_vertex.png)
In both cases, the shader pipeline renderer was used.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/81CameraNode broken?2017-05-04T12:33:24ZChristopher TenterCameraNode broken?There seems to be an issue with the CameraNode draw implementation. This is a screen of the CameraNode draw result for a perspective projection:
![camera_draw](/uploads/95a7c65e0b9e460b079daaeed9296997/camera_draw.png)
This is the ac...There seems to be an issue with the CameraNode draw implementation. This is a screen of the CameraNode draw result for a perspective projection:
![camera_draw](/uploads/95a7c65e0b9e460b079daaeed9296997/camera_draw.png)
This is the actual frustum (own render code):
![expected_frustum](/uploads/93fbe38146bd8f73a14459140d6aa0d5/expected_frustum.png)
Also, the CameraNode assumes a perspective projection, so should be reworked to accept any type of frustum matrices.
There are many redundant settings necessary to setup the CameraNode:
- setSize()
- setFarPlane()
- setNearPlane()
The frustum is already fully defined by the view and projection matrix, so these are obsolete.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/80Vector11T template deduction error on msvc2017-05-04T12:33:24ZChristopher TenterVector11T template deduction error on msvcThere is a strange compile error with the following triangle bsp code:
`TriMeshObject* obj = PluginFunctions::triMeshObject(o_it->id());
TriMeshObject::OMTriangleBSP* bsp = obj->requestTriangleBsp();
TriMeshObject::OMTriangleBSP::Ra...There is a strange compile error with the following triangle bsp code:
`TriMeshObject* obj = PluginFunctions::triMeshObject(o_it->id());
TriMeshObject::OMTriangleBSP* bsp = obj->requestTriangleBsp();
TriMeshObject::OMTriangleBSP::RayCollision rc = bsp->nearestRaycollision(ACG::Vec3d(0.0, 0.0, 0.0), ACG::Vec3d(1.0, 0.0, 0.0));`
Error (vs2015 sp3):
`20>d:\openflipper-free-masterthesis\acg\geometry\bsp\BSPImplT.cc(173): error C2783: 'OpenMesh::VectorT<double,3>::VectorT(T...)': could not deduce template argument for '<unnamed-symbol>'
20> d:\openflipper-free-masterthesis\libs_required\openmesh\src\openmesh\core\geometry\Vector11T.hh(119): note: see declaration of 'OpenMesh::VectorT<double,3>::VectorT'
20> d:\openflipper-free-masterthesis\acg\geometry\bsp\BSPImplT.cc(170): note: while compiling class template member function 'std::vector<std::pair<OpenMesh::FaceHandle,double>,std::allocator<_Ty>> BSPImplT<TriangleBSPCoreT<BSPTraits>>::nearestRaycollision(const OpenMesh::VectorT<double,3> &,const OpenMesh::VectorT<double,3> &) const'
20> with
20> [
20> _Ty=std::pair<OpenMesh::FaceHandle,double>,
20> BSPTraits=OVMOMCommonTriangleBSPTraits<TriMesh,OMSpecificTriangleBSPTraits<TriMesh>>
20> ]
20> D:\OpenFlipper-Free-MasterThesis\Plugin-RasterSurfaceRecon\SceneAnalyzer.cc(171): note: see reference to function template instantiation 'std::vector<std::pair<OpenMesh::FaceHandle,double>,std::allocator<_Ty>> BSPImplT<TriangleBSPCoreT<BSPTraits>>::nearestRaycollision(const OpenMesh::VectorT<double,3> &,const OpenMesh::VectorT<double,3> &) const' being compiled
20> with
20> [
20> _Ty=std::pair<OpenMesh::FaceHandle,double>,
20> BSPTraits=OVMOMCommonTriangleBSPTraits<TriMesh,OMSpecificTriangleBSPTraits<TriMesh>>
20> ]
20> d:\openflipper-free-masterthesis\acg\geometry\bsp\TriangleBSPT.hh(74): note: see reference to class template instantiation 'BSPImplT<TriangleBSPCoreT<BSPTraits>>' being compiled
20> with
20> [
20> BSPTraits=OVMOMCommonTriangleBSPTraits<TriMesh,OMSpecificTriangleBSPTraits<TriMesh>>
20> ]
20> d:\openflipper-free-masterthesis\acg\geometry\bsp\TriangleBSPT.hh(223): note: see reference to class template instantiation 'TriangleBSPT<OVMOMCommonTriangleBSPTraits<Mesh,OMSpecificTriangleBSPTraits<Mesh>>>' being compiled
20> with
20> [
20> Mesh=TriMesh
20> ]
20> D:\OpenFlipper-Free-MasterThesis\Plugin-RasterSurfaceRecon\SceneAnalyzer.cc(171): note: see reference to class template instantiation 'OpenMeshTriangleBSPT<MeshT>' being compiled
20> with
20> [
20> MeshT=TriMesh
20> ]`Janis BornJanis Bornhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/79Fix warning2017-05-04T12:33:24ZJan Möbiusmoebius@cs.rwth-aachen.deFix warninge:\gitlab\builds\2dad8761\0\openflipper-free\openflipper-free\acg\gl\DrawMeshT.cc(263): warning C4267: "return": Konvertierung von "size_t" nach "int", Datenverlust m�glich
131> e:\gitlab\builds\2dad8761\0\openflipper-free\openflipper-...e:\gitlab\builds\2dad8761\0\openflipper-free\openflipper-free\acg\gl\DrawMeshT.cc(263): warning C4267: "return": Konvertierung von "size_t" nach "int", Datenverlust m�glich
131> e:\gitlab\builds\2dad8761\0\openflipper-free\openflipper-free\acg\gl\DrawMeshT.cc(263): note: Bei der Kompilierung der Klassen-template der "int ACG::DrawMeshFaceInput<Mesh>::getNumFaces(void) const"-Memberfunktion
131> with
131> [
131> Mesh=TriMesh
131> ]
131> e:\gitlab\builds\2dad8761\0\openflipper-free\openflipper-free\acg\gl\DrawMeshT.cc(568): note: Siehe Verweis auf die Instanziierung der gerade kompilierten Klassen-template "ACG::DrawMeshFaceInput<Mesh>".
131> with
131> [
131> Mesh=TriMesh
131> ]
131> e:\gitlab\builds\2dad8761\0\openflipper-free\openflipper-free\acg\gl\DrawMeshT.cc(408): note: Bei der Kompilierung der Klassen-template der "void ACG::DrawMeshT<Mesh>::rebuild(void)"-Memberfunktion
131> with
131> [
131> Mesh=TriMesh
131> ]OpenFlipper-4.0https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/77Wrong cmake subsystem configuration in console mode on Windows (WIN_GET_DEBU...2017-05-04T12:33:24ZChristopher TenterWrong cmake subsystem configuration in console mode on Windows (WIN_GET_DEBUG_CONSOLE)With the cmake flag WIN_GET_DEBUG_CONSOLE enabled on windows, OpenFlipper starts with a console but no output is ever written to it. This is caused by the misconfigured subsystem flag in the OpenFlipper project properties after running c...With the cmake flag WIN_GET_DEBUG_CONSOLE enabled on windows, OpenFlipper starts with a console but no output is ever written to it. This is caused by the misconfigured subsystem flag in the OpenFlipper project properties after running cmake. So there is actually no debug output in the console.
The subsystem is always set to /SUBYSTEM:WINDOWS, which prevents output streams to the console. The subsystem should be dependent of the WIN_GET_DEBUG_CONSOLE flag to fix this issue. If it is enabled, then /SUBSYSTEM:CONSOLE should be used, otherwise /SUBSYSTEM:WINDOWS.
Apparently it can be controlled by the "WIN32" flag in add_executable()
https://stackoverflow.com/questions/8497948/vs10-always-links-to-subsystemwindows-cmakesdlglewhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/75PropertyVisualizer histograms?2017-05-04T12:33:26ZMartin HeistermannPropertyVisualizer histograms?For me it would be quite useful to compute histograms for property values and on the suggestion of @dbommes I'm currently trying to add support for this to the property visualizer.
Would that be appreciated? I'm asking now, as otherwise...For me it would be quite useful to compute histograms for property values and on the suggestion of @dbommes I'm currently trying to add support for this to the property visualizer.
Would that be appreciated? I'm asking now, as otherwise, I'd save some effort by implementing it in a standalone plugin and wouldn't have to restrict myself to C++98 & Qt4 compat.
I'm currently adding a "show histogram" button to the bottom of the toolbox for appropriate properties (for my purposes, double is enough, but int and bool seem very reasonable too), which would then add a Qwt based histogram inline below, possibly with some controls over bin sizes etc. However I'm very open to suggestions here.
@moebius : If you're interested in this feature, is there some way I could use the CI infrastructure for my own dev branch, so I don't have to duplicate it? (I noticed the CI fails on my PRs as it apparently can't access the git refs in my clone?)https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/74ShaderPipeline: Overlay Flag Handling Buggy2017-07-26T08:09:31ZHans-Christian EbkeShaderPipeline: Overlay Flag Handling BuggyThe shader pipeline renderer supports the overlay flag of render objects. If it is set, the object is rendered in a second pass above everything of the first pass. This sort of works, but not always.
The following screen shots show one g...The shader pipeline renderer supports the overlay flag of render objects. If it is set, the object is rendered in a second pass above everything of the first pass. This sort of works, but not always.
The following screen shots show one good case and one failure case:
![bug1](/uploads/c720132cba7ab509488043cbfbc333b5/bug1.png)
![bug2](/uploads/a28439aa97a6f7a6171ddc071d4a6124/bug2.png)
If I had to guess, I'd say it is some issue with the Z-Buffer. Maybe it's not cleared properly before the second pass?