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/96Angle Based Edge Selection2017-04-20T10:23:35ZMartin SchultzAngle Based Edge Selection* is the angle given in Radians?
* add a tooltip for max Angle
* is this angle only for floodfill slection, or does it apply to other cases too?* is the angle given in Radians?
* add a tooltip for max Angle
* is this angle only for floodfill slection, or does it apply to other cases too?Martin SchultzMartin Schultzhttps://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/78ptr namespace and make_unique2017-05-04T12:33:24ZMartin Heistermannptr namespace and make_uniqueHi,
currently, OF (at ACG/Utils/SmartPointer.hh) and OVM (at System/MemoryInclude.hh) have (nearly?) identical support code to get shared_ptr and unique_ptr from the correct namespace for pre-c++11 compilers.
This should be obsolete now...Hi,
currently, OF (at ACG/Utils/SmartPointer.hh) and OVM (at System/MemoryInclude.hh) have (nearly?) identical support code to get shared_ptr and unique_ptr from the correct namespace for pre-c++11 compilers.
This should be obsolete now in OF (not sure about OVM, will that still support pre-c++11 for the foreseeable future?).
However, support for make_unique [0] would be great - it's very useful, but unfortunately didn't make it into c++ before c++14, but luckily the common non-array version is a straightforward one-liner to implement.
In case OVM does not require pre-c++11 support anymore, I would propose turning ptr from a namespace alias into a proper namespace with adds legacy code support using "using std::unique_ptr" (+shared_ptr, +make_shared - anything else?), and, depending on the C++-version, implements its own basic make_unique.
If not, my suggestion would be putting it somewhere else instead of reusing the old ptr namespace (/namespace alias).
Looking forward to hearing your thoughts on this!
[0] http://en.cppreference.com/w/cpp/memory/unique_ptr/make_uniqueJan Möbiusmoebius@cs.rwth-aachen.deJan Möbiusmoebius@cs.rwth-aachen.dehttps://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-cmakesdlglew