Greetings,
I found myself wanting to use the Decimater plug-in in batch mode (-b), but
the existing plug-in does not support GUI-less operation. You will see a
warning such as the following when running in batch mode:
Core : Running in nogui mode which is unsupported by this plugin,
skipping
I have attached a patch that allows the Decimater to be run in batch mode.
Can this be added to the repository?
Kind regards,
--Ian
Hi,
thank you for your answer.
> What you mean by keeping the surface structure? The topology of one mesh
> or the order of the triangles? If i get it right you need to repair
> multiple touching surfaces and that you need to repair both in the same
> way, which is currently not implemented.
I did not get what you mean by "repair both in the same way"...
By keeping the surface structure, I mean that the surfaces should not be collapsed into one, as is the case for stl format AFAIK. A cube, for example, has 6 outer surfaces, and those should also be 6 different surfaces in the mesh file (with identical nodes at the edges, of course). So it is not at the triangle level, but at the surface level that the structure must be preserved when the repair is done.
As an example, imagine two cubes, one on top of the other, but shifted in horizontal direction (see attachment: Test_partial_2D_mesh.png). The common interface between both is a part of the bottom surface of the upper cube, and a part of the upper surface of the lower cube. gmsh cannot do the merge at the interface, so it would create two overlapping nonconformal meshes (attachment: Test_partial_2D_interface.png). The triangles and nodes at the interface would not be identical. Now I would need a tool which detects the overlap at the interface and repairs it. The result would have to be that the interface is cut out from the upper surface of the lower and the bottom surface of the upper cube, and the holes replaced by a new surface common to both cubes. At the lines limiting the interface, the meshes must share nodes (attachment: Test_partial_2D_clean.png).
I hope that this makes clear what I want to do.
Would OpenFlipper be able to do this? If not, do you have a hint where else I could look?
Thanks,
Matthias
_____________________________________________________________________
ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Hi,
I am looking for a way to repair a surface mesh generated by gmsh, and would like to know if this is possible.
I explain my problem in some more depth:
I am doing FEM simulations and need to generate meshes from CAD data which I get in STEP format. The geometries normally consist of several volumes which are in contact with each other, so they share common interfaces. In CAD, each volume has its own set of outer surfaces, so that there are duplicated interfaces between the volumes. For FEM, the mesh needs to be conformal at the interfaces, i.e. there needs to be only one surface with its nodes and triangles between the volumes. I am using gmsh (http://geuz.org/gmsh) to generate the mesh. The problem is that gmsh cannot repair those duplicated interfaces. So what I want to do is
* generate a surface mesh with gmsh
* export it, use a mesh manipulation program to repair the mesh at the duplicated interfaces
* re-import the repaired mesh into gmsh and generate the 3D mesh.
My question: Is this possible with OpenFlipper?
I have installed OpenFlipper and tried to import a surface mesh from gmsh, but I did not find a format which gmsh writes that can be opened by OpenFlipper. gmsh writes msh (its own format), inp, unv, wrl, and some more. It is important that the surfaces structure (i.e. there are several surfaces, not just one) is kept during the process, so stl is not an option as far as I understand.
Which mesh formats (except OpenMesh) can be read by OpenFlipper? Or is there a way to convert a mesh from gmsh to OpenMesh format?
If it is not possible with OpenFlipper, do you know another software I could use for this purpose?
Thank you for some hints,
Matthias
_____________________________________________________________________
ERBE Elektromedizin GmbH
Firmensitz: 72072 Tuebingen
Geschaeftsfuehrer: Christian O. Erbe, Reiner Thede
Registergericht: Stuttgart HRB 380137
Hello everybody,
I tried to install only openmesh, in particular version 2.3.1.
After using cmake with the gcc 4.7 compiler,
(
here is the command
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/OpenMesh
-DCMAKE_CXX_COMPILER=/usr/gcc_4_7/bin/g++-4.7
-DCMAKE_C_COMPILER=/usr/gcc_4_7/bin/gcc-4.7
)
and a successful make command, I got the following make install error:
...
[100%] Built target Synthesizer
[ 21%] Built target OpenMeshCore
[ 43%] Built target OpenMeshCoreStatic
[ 50%] Built target OpenMeshTools
[ 58%] Built target OpenMeshToolsStatic
[ 59%] Built target Dualizer
[ 60%] Built target commandlineDecimater
[ 61%] Built target Smoothing
[ 62%] Built target commandlineSubdivider
[ 63%] Built target commandlineAdaptiveSubdivider
[ 64%] Built target mconvert
[ 65%] Built target mkbalancedpm
[ 65%] Built target Analyzer
[ 74%] Built target DecimaterGui
[ 80%] Built target QtViewer
[ 88%] Built target SubdividerGui
[ 94%] Built target ProgViewer
[100%] Built target Synthesizer
Install the project...
-- Install configuration: "Release"
CMake Error at src/OpenMesh/Core/cmake_install.cmake:54 (FILE):
file INSTALL cannot find
"*********************/OpenMesh-2.3.1/build/Build/lib/OpenMesh/libOpenMeshCore.so.2.3".
Call Stack (most recent call first):
cmake_install.cmake:37 (INCLUDE)
make: *** [install] Fehler 1
As one can see, the cmake command uses the default Debug configuration,
so why is the install configuration "Release" used?
Is this a bug?
Best regards,
Marcel Makowski
--
Dipl.-Math. Marcel Makowski
Institut für Geometrie und Praktische Mathematik
RWTH-Aachen
Templergraben 55
D-52056 Aachen, Germany
email: makowski(a)igpm.rwth-aachen.de
Phone: +49-241-80-97066
Fax: +49-241-80-92317
URL: http://www.igpm.rwth-aachen.de
Hey all,
I want to do some simulation on meshes using OpenFlipper. Now I encounter a
problem. In the simulation, I want to update the scene every step. The
pseudo code like
/********
func()
{
...
Loop:
do something about the mesh (object);
updatedObject();
updateView();
EndLoop
}
********/
But actually it only shows the final view of the object for the whole
process. I want to view the whole process of the simulation. How can I do
with that? Would you please give me some advices?
Thanks
--
Best regards,
Bo Wu
Hi,
In my plugin I want to group objects together. To this end, following the Datacontrol plugin's file Popup.cc I implemented the grouping and it works well. However, the code emits the signal emptyObjectAdded from LoadSaveInterface which is deprecated according to the documentation. It is not really an issue, but what is then the correct way of creating groups of objects?
Thanks,
Vladimir
Dear OpenFlipper maintainers,
Are there any plans to eventually support also DXF as an I/O file format in
OpenFlipper?
I understand that this is just the question for somebody to write a
corresponding plugin. After having successfully compiled and built the
OpenFlipper sources from SVN, I could even imagine to write and contribute
some basic support myself, at least as far as my own interest in that
format goes: supporting plain triangulated meshes without any further
"decorations" like normals, textures etc. I would use for that purpose the
DIME library (open source, rather old, but still doing its job so far...)
which I changed so far that it now works with double numbers instead of
float only internally. I guess that this would be a question of a few more
hours to get that running on my computer.
Much more of a problem I see in the integration into the OpenFlipper
system: How to handle the extra DIME library? How to integrate all that
license stuff properly? How to tell that fabulours CMake system that there
is now another library to take care of? etc. etc. And since I am having
absolutely no clue about that CMake magic, nor with these license
subtleties, I would spend probably much more time with these issues than
with the actual implementation of the DXF plugin!
Bottom line: from my part, I have no objections against integrating any
such DXF plugin into the main OpenFlipper project, but I see many technical
and understanding problems on my side in terms of realizing such an
integration properly! An alternative for me only would of course be to
build such an extension to the OpenFlipper only for myself and my
colleagues, for our own work.
Regards,
Cornelis Bockemühl
_____________________
Cornelis Bockemühl
Holcim Group Support Ltd
Cement Manufacturing Services
Materials Technology
Reserve Evaluation and Quarry Planning
Im Schachen
CH-5113 Holderbank
Phone +41 58 858 51 30
Fax +41 58 858 51 51
cornelis.bockemuehl(a)holcim.com
www.holcim.com
Holcim – 100 years of Strength. Performance. Passion.
This e-mail is confidential and intended only for the use of the above
named addressee. If you have received this e-mail in error, please delete
it immediately and notify us by e-mail or telephone.
Dear OpenFlipper friends and developers,
We are just now running into a problem while using the OpenFlipper for topo
modelling and model simplification with the Decimater. The point is that
geographical coordinates tend to be large numbers, but in some way you can
say that the most significant digits are the least significant ones -
because they never change throughout a model!
The problem is that once we have "decimated" a model and want to write it
out to an OBJ file, the least significant digits are cut off by the C++
automatism of switching to exponential notation if numbers are getting
large:
4522765.277 -> 4.52277e006
Which means: rounding to the next 10m occurs - not really acceptable!
Of course we are already practising the workaround of first shifting the
coordinates to something lower, then do the OpenFlipper treatment, then
shift back. But of course it would be nicer if the OpenFlipper would simply
do the output with some explicit fixed formatting. Currently the code that
outputs the coordinates in OBJ format is the following:
// Write out vertex coordinates
_out << "v " << v[0] <<" "<< v[1] <<" "<< v[2] << std::endl;
This code is at FileOBJT.cc(299). Would it be possible to add some
formatting to such output lines, in order to make it easier to work with
large coordinate values? Or is there a danger that in such a case there
would be people complaining that they are now not any more able to work in
picometers properly? ;-)
Regards,
Cornelis
_____________________
Cornelis Bockemühl
Holcim Group Support Ltd
Cement Manufacturing Services
Materials Technology
Reserve Evaluation and Quarry Planning
Im Schachen
CH-5113 Holderbank
Phone +41 58 858 51 30
Fax +41 58 858 51 51
cornelis.bockemuehl(a)holcim.com
www.holcim.com
Holcim – 100 years of Strength. Performance. Passion.
This e-mail is confidential and intended only for the use of the above
named addressee. If you have received this e-mail in error, please delete
it immediately and notify us by e-mail or telephone.