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.
