OpenFlipper-Free issueshttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues2017-05-02T17:37:36Zhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/99Check VS2013 build error (OM Test fail?)2017-05-02T17:37:36ZJan Möbiusmoebius@cs.rwth-aachen.deCheck VS2013 build error (OM Test fail?)OpenFlipper-4.0Martin SchultzMartin Schultzhttps://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-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/73Plugin Convert Meshes2017-05-04T12:33:26ZJan Möbiusmoebius@cs.rwth-aachen.dePlugin Convert MeshesConvert between tri and polymesh preserving properties.Convert between tri and polymesh preserving properties.Martin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/72Plugin-MergeMeshes2017-05-04T12:33:26ZJan Möbiusmoebius@cs.rwth-aachen.dePlugin-MergeMeshesPlugin-MergeMeshes
Toolbox icon:
Merge all Target meshes into one mesh.
Ask for new name
Checkbox if old ones should be removed
Preserve properties if possible.
Copy Property function (in OpenMesh)
Ask if different typesPlugin-MergeMeshes
Toolbox icon:
Merge all Target meshes into one mesh.
Ask for new name
Checkbox if old ones should be removed
Preserve properties if possible.
Copy Property function (in OpenMesh)
Ask if different typesMartin SchultzMartin Schultzhttps://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/71More efficient PrincipalAxisNode rendering2017-05-04T12:33:26ZHans-Christian EbkeMore efficient PrincipalAxisNode renderingPrincpialAxisNode (ACG/Scenegraph/PrincipalAxisNode.cc) is rendered in a rather inefficient manner: Axis nodes consist of only 3 colors but every vertex has its individual color. That's some major waste of GPU memory. At the point of thi...PrincpialAxisNode (ACG/Scenegraph/PrincipalAxisNode.cc) is rendered in a rather inefficient manner: Axis nodes consist of only 3 colors but every vertex has its individual color. That's some major waste of GPU memory. At the point of this writing, the file in question is not yet merged into master but in branch move_principal_axis_node_from_physim.https://gitlab.vci.rwth-aachen.de:9000/OpenFlipper-Free/OpenFlipper-Free/-/issues/70Crash when rendering poly lines w/ default internal renderer2017-05-04T12:33:26ZHans-Christian EbkeCrash when rendering poly lines w/ default internal rendererOpenFlipper immediately crashes when displaying poly lines with the default internal renderer. Using the shader pipeline, everything appears to work smoothly.
# Steps to Reproduce
* start OpenFlipper
* set renderer to *Shader Pipe...OpenFlipper immediately crashes when displaying poly lines with the default internal renderer. Using the shader pipeline, everything appears to work smoothly.
# Steps to Reproduce
* start OpenFlipper
* set renderer to *Shader Pipeline*
* open the attached [test.pol](/uploads/ced0dcb7ed7d0f69fcc1209cc9dc0f1f/test.pol)
* the poly line is displayed normally
* switch renderer to *Default Internal*
* *crash*