Digitizer Import plugin

[GeoffreyGRoy]

Many thanks for all the feedback and comments.  I have attached a new version (1.0.3).

Some fixes and changes:

(1) The dialog has been made a little larger to make more space for labels, and the labels right justified to better fit translated strings.

(2) I have not been unable identify when CamBam has a model already loaded, and CamBam does not check this itself when loading a new STL file -if this can be done I will try and create a test/confirmation. Also CamBam does not seem to check that a save has not occurred after directly loading a STL model.  If this is possible please let me know.

(3) Hitting "Cancel" will now zero the progress bar

(4) The "prop.txt" file has problems.  I have fixed the error - caused by the progress bar going out of range, but that does not solve the problems with generating triangles for this file.  The Delaunay triangulation algorithm expects only 2.5D data (like a relief model) - it will not cope with 3D data and it will not cope with data where there exists multiple points with the same X,Y coordinates and I suspect this is the problems with this point cloud example.  It might be possible to filter out such data, but this will depend on what model is being developed and whether this is a valid step.

(5) As mater of interest i need to estimate the number of triangles in advance to correctly show the progress bar.  Theoretically this is given by 2n-2-k, where n is the number of points in the cloud and k is the number of points on the convex hull.  I can only estimate k for clouds that are digitized on a rectangular pattern, so the progress bar may give somewhat misleading results in some cases.

(6) I have tied to improved the data parsing to cope with European and Non-European number formats (see User guide for details).  It should now work with <.> decimals and <,> separators  (Non European) and <,> and <;> for European;  <sp> separators can also be used.  This is not foolproof but it might save doing global replacements to reformat data files.  The behaviour might also change if your computer does not have a "en" current culture setting.

(7) I have added a new button <Data Details> that will pop up a dialog giving the actual and scaled coordinates of where the various maxima and minima coordinate locations occur - after loading a data file and setting the offsets and scaling parameters.

( I have corrected the (missing) header in the STL file, though I think  can leave the full file name in place.

Please try this out and let me know how you get on.

Geoff

[lloydsp]

I was just kidding around with you, Ralf.

I once saw "the world's longest word", and it was - as are many - one of those German 'composite' words -- like 130 letters long, or something.  Just HUGE! <G>

Lloyd

[dh42]

Hello Geoff,

The pb with the STL format is solved but for the UI it's worst than the previous version ...  



If you want and if you share sources, I can help you to do the form settings for the UI (without changing anything in your code)

Also CamBam does not seem to check that a save has not occurred after directly loading a STL model.  If this is possible please let me know.

I think that after the 3D surface is created, you must set the "modified" flag.

ex in VB:

CamBamUI.MainUI.ActiveView.CADFile.Modified = True

you can also test this value before erasing the current drawing.

++
David

[pixelmaker]

hello,
no there is something totally wrong with the stl files.
The first line still shows the path to the file.
The structure for ascii STL files is
solid
 ...
 facet normal 0.00 0.00 1.00
    outer loop
      vertex  2.00  2.00  0.00
      vertex -1.00  1.00  0.00
      vertex  0.00 -1.00  0.00
    endloop
  endfacet
 ...
 endsolid

The problem if the path is in the header occurs if I work in a network and the HD (Y:\) is different from the different PC. A HD is from the first PC C:\ and rom the second Y:\

. But the filename must no be in the first line. I try this and the files work if in the first/last line is only a solid/endsolid.

The bigger problem are the decimal comma instead of the decimal points.
Here I read :"where each n or v is a floating-point number in sign-mantissa-"e"-sign-exponent format, e.g., "2.648000e-002" .

The coordinates are sometimes with a decimal point (facet normal) and then with a comma (vertex).
But all coordinates must have a decimal point. I can´t open the saved stl file. Not in Cambam and not in a different software. Meshlab tells me again the "Error details: Premature End of file"
After changing all comma to points (in the vertex coordinates) the file work in every software.
If I check the option "open in cambam" the file opens in CB correctly.

Example:
The attached file armando2.txt. If I check the option "open in cambam" in your plugin I get a object with the size:
Min : 0,0,0
Max : 68.61,65,36.568
Breite (X) : 68.61
Höhe (Y) : 65
Tiefe (Z) 36.568
It is correct in cambam, but the saved STL file I can´t open in different software (e.g. Meshlab, C4D, Blender)

If I reopen the Armando2.stl in Cambam from the disk I get a wrong size and I get a wrong facet orientation:

Min : 0,0,0
Max : 68610000,65000000,36568000
Breite (X) : 68610000
Höhe (Y) : 65000000
Tiefe (Z) 36568000

I open the Armando2.stl in a text editor, I delete the path and filename from first and last line and change all comma(,) to points (.)
I save this file as Armando2_comma2points.stl
If I open this file in Cambam I have no problems to open it and it has the right size. Also in the other software I get no error
The 3 files are attached in a zip archive.

I am very surprised that you have no problems with the stored STL files.

ralf

[dh42]

Hello,

For me that works with 3dsmax without warning ; SolidWorks display a warning (wrong facet normal) but open the file.

A guy on a French forum can't open the file with Aspire.(I can't test I have not this soft)

the test file:
http://www.usinages.com/ressources/file/197110

++
David

[pixelmaker]

David,
I can´t open the saved STL files in Cambam!
I get a totally wrong size and see nothing but a big big black sheet.
The object size is 1 million times larger then the original object.
And it is the same if I save the files to my windows hd or my mac hd.  

piece.txt, object generated with activated option "Load into Cambam", screenshot 1

Selected Objects Extrema :
Min : 0,0,0
Max : 10.00458,14.00191,0.24643
Width (X) : 10.00458
Height (Y) : 14.00191
Depth (Z) 0.24643

File piece.stl open in Cambam from the harddisk, screenshot 2, you see the wrong facets:

Selected Objects Extrema :
Min : 0,0,0
Max : 10004580,14001910,246430
Width (X) : 10004580
Height (Y) : 14001910
Depth (Z) 246430

This is a magnification factor from 1 million. This can´t be of different graphic card options. It can only come from the separator sign that Cambam can´t work with.

I open the piece.stl in a text editor (text wrangler) and I replace the commas by points (63000 comma replaced with points) and save as "piece_comma2point.stl".

If I open this file in Cambam I get the right size and no problems with wrong faces.
The problem in the stl files are the comma as decimal point in the coordinates of the vertex coordinates.
As I have already written in the STL file format the dot /point is prescribed as the decimal separator. Search for simply "STL ASCII File Format" . You never see a code sample with comma as separator.

In the attached archive "piece_stl.zip" you find the from the plugin generated STL file and the changed STL file.


ralf

[dh42]

Hello Ralf,

Yes the pb is with the comma when using "," for decimal in regional settings.. (I always use "." thats explain why it work well for me)

@geoff,

I had the same problem on my converter ; the pb appears because when you use the Format() function to create the number, windows automatically change . by , according to the regional settings and I can't found a way to "fix" the dot for the Format function .

The only way I found that works without pb is:

- use the format() function to format the number
- use the Replace() function on the formatted text to replace , by . if needed

look on my code (Mach3digit2STL) in the sub SaveSTL()

Code: [Select]

ligne = "      vertex " & Format(f(pos, 0), "e") & " " & Format(f(pos, 1), "e") & " " & Format(f(pos, 2), "e")
PrintLine(1, Replace(ligne, ",", "."))     'replace "," by  "."
++
David

[lloydsp]

Replace will vastly slow down the process.

I generally find, if a required sequence is expected, that building the string by concatenation is the best way (probably also fastest).

Lloyd

[pixelmaker]

hello David

Yes the pb is with the comma when using "," for decimal in regional settings.. (I always use "." thats explain why it work well for me)

I am not the windows guru. Where can I change this?

ralf

[lloydsp]

"Localization settings"

Lloyd

[pixelmaker]

Localisation settings -> Advanced settings 

Ok now it works. But I think this is not the solution.
There is a difference between the coordinates in the STL file (without changing the localisation settings)
The coordinates for facet normal are separated with dots, only the vertex coordinates are separated with comma.

This works now and I am shure that every german user who download the plugin ask me why the stl don´t work 

ralf

[lloydsp]

Like I said, Ralf; don't rely on Windows's inherent functions when you want _exact_ output.  Do explicit string concatenations.  It's generally fast, doesn't require calling lots of system resources, and gives you exactly what you expected every time.

Lloyd

[dh42]

Ralf, another way to do as a workaround until Geoff repair the plugin. 

use the plugin with 'load into cambam'
save the cambam file that contain the 3d object
use my extractor to extract the stl from the .cb file.
http://www.cambam.co.uk/forum/index.php?topic=2287.0

++
David

[GeoffreyGRoy]

Wow! lots of feedback.  Version 1.0.4 attached:

(1) Most of the problems seem relate to number formats, especially in the STL file.  I had  (perhaps) naively assumed that the STL file format could contain European formats and that CamBam would load them correctly.  Obviously not.  I now create the STL file using decimal points <.> by forcing an "en" culture and not relying on that set in your machine.  If this causes problems I can try again.

(2)  The form layout has been changed back to "LeftCenter" text align, and I have moved the labels back to the left.  This might help most translations.  The suggestion to use "RightCenter" alignment did not work, obviously - I have missed something here - suggestions appreciated.

(3) I have added a data validation step that can be used to identify "bad" data before trying the triangulation is attempted.  If the <Validate> checkbox is checked then a validation step is done first.  If errors are found they are reported with an option to save the the referenced points to an error file.  Some "errors" may not prevent a good triangulation, so un-check the Valid checkbox and try again without the check.  The suk.txt file, for example, does report some errors but still creates a good surface.  The prop.txt file reports lots of errors and fails to solve the triangulation.  Reported errors include points that have the same (X,Y) and different Z, and those that have identical (X,Y,Z) values.  If no errors are found the triangulation step proceeds as normal.

(4) I have removed the input file name from the STL header and footer. I am not convinced that this is a problem, but is now gone.

(5) Warnings now apply when loading the plugin and when exiting CamBam to prevent loss of data.

thanks for the feedback.

Geoff

[pixelmaker]

Hello Geoff,
I have tested the version 1.0.4. The regional settings I have set back. The STL files now work correctly in all tested programs. I thank you for the many changes. I'll make tonight the German translation ready and take it in the language file.

The UI now looks very good, thank you for this.

One question I have. When I select validation does not always appear the window with the errors. If the window is opened only when errors occur?

If no errors are found the triangulation step proceeds as normal.

Means no window will open?


@Lloyd: The actual longest german word in the dictionary has 36 letters, but is  a hyphenated word. If you write 777,777 in german words you get a 65 letter word. But for what, we have numbers.
The longest english word in the dictionary has 45 letter and I think there are some Welsh place names there are longer.
But the longest existing word is a english word and it has 189819 letters, the full name of Titin. and need 3 and a half hour.


ralf