cut tech thread: virtual facet size

[Rhino]

Date: 12/22/2006 3:04:47 AM
Author: adamasgem

Date: 12/21/2006 8:16:33 PM
Author: Rhino
Interestingly this file is generated from the same scan except as observed via OGI''s Web Viewer software. Each upper half facet is resolved and each upper half angle can easily be read by simply clicking on the facet. To my knowledge these software changes will be reflected in the update that''s on its way.

Marty, look at the meet point faceting as well.

The OGI generates .stl files also and when I attempted an import into DiamCalc, for some reason it wouldn''t let me import the file. I was able to open the .stl file with a program Pete had turned me onto called ''Solid View'' and the model appeared as it does in the first graphic I posted above.

When I saw the model here generated by the OGI and if this is reflected in the new updates coming down the pike, I thought this was an excellent improvement and I look forward to getting their updated scanner/software on this.

Sarin next...

Would you email me the stl file..

Check your mail Marty.

Serg ... I''m noting that the DiamCalc isn''t importing certain .stl files. I note in the software that it can export binary and ascii .stl files. Is DC only able to import certain types of .stl''s? The .stl''s generated from OGI aren''t able to import to DC. For some reason my emails to you are getting kicked back. Did you change your email? If so, please send me new one.

Regards,

 

[adamasgem]

Rhino The OGI file is in binary, so can''t make head or tail of it...Right now I parse out an ascii STL file, as I suspect Sergey does..

 

[Rhino]

Perhaps Sergey can make the DC import binary .stl''s? Either that or I''ll give OGI a call and see if they can make a fix to export ascii.

 

[adamasgem]

Date: 12/24/2006 12:02:53 PM
Author: Rhino
Perhaps Sergey can make the DC import binary .stl''s? Either that or I''ll give OGI a call and see if they can make a fix to export ascii.

There is more than that binary problem. Here is the OGI stl file you sent me imported into MeshWorks..

It DOESN"T give me any warm and fuzzy feeling regarding OGI, and is inconsistent with the rendering you posted..

Unfortunately, since it is in some standard form of STL binary that I don''t know the format of, I can''t help much..

 

[RockDoc]

Date: 12/24/2006 12:09:39 PM
Author: adamasgem

Date: 12/24/2006 12:02:53 PM
Author: Rhino
Perhaps Sergey can make the DC import binary .stl''s? Either that or I''ll give OGI a call and see if they can make a fix to export ascii.

There is more than that binary problem. Here is the OGI stl file you sent me imported into MeshWorks..

It DOESN''T give me any warm and fuzzy feeling regarding OGI, and is inconsistent with the rendering you posted..

Unfortunately, since it is in some standard form of STL binary that I don''t know the format of, I can''t help much..

Neat looking graphic, Marty.......


MeshWorks...hmmmm ain''t that the gizmo that you make pasta with? Or maybe it makes aluminum into tinsel, on Christmas?



Rockdoc (Compu- Grape Humor)

 

[adamasgem]

Date: 12/24/2006 12:34:09 PM
Author: RockDoc


Neat looking graphic, Marty.......
Graphic sucks .. which says the data is questionable..

MeshWorks...hmmmm ain''t that the gizmo that you make pasta with? Or maybe it makes aluminum into tinsel, on Christmas?
Compu grape

Rockdoc (Compu- Grape Humor)

 

[Garry H (Cut Nut)]

Date: 12/21/2006 8:11:23 PM
Author: Rhino
A peek to the future ...

You''ll note in this first screenshot taken within the OGI software itself it''s difficulty resolving the upper half facets becuase their angles are so so close to the actual crown mains. Stones like this are the hardest for a scanner to detect however OGI has pointed out to me that their scanner does indeed *see* these facets but the model in the current software isn''t showing them. More on this in the next graphic.

Some scanner companies attepmt to use their software to ''average'' out stone defects and make their models symetrical.

It adds a kind of '' surveyors loop closing arithmatic error ''.

What you showed was an excellent example where they get caught out Rhino.

 

[Serg]

re:It DOESN"T give me any warm and fuzzy feeling regarding OGI, and is inconsistent with the rendering you posted.
Unfortunately, since it is in some standard form of STL binary that I don't know the format of, I can't help much..


Marty,

I received same result with Rhono OGI stl file. Model is not convex even. just garbage
I have sent model to Garry and Rhino in DC format

 

[adamasgem]

Date: 12/25/2006 10:25:23 AM
Author: Serg

re:It DOESN''T give me any warm and fuzzy feeling regarding OGI, and is inconsistent with the rendering you posted.
Unfortunately, since it is in some standard form of STL binary that I don''t know the format of, I can''t help much..


Marty,

I received same result with Rhono OGI stl file. Model is not convex even. just garbage
I have sent model to Garry and Rhino in DC format

You noticed that, did you

If they can''t create a STL file, I wonder what the rest of their rendering "model" is based on..

Did you figure out what format the data is in.. If so I''d appreciate knowing...

 

[RockDoc]

RE : OGI Format

Gee Marty.... that''s easy.....


It''s a sub derivative called KLBSBasic... ( Kitty Litter Box Scanner Basic ) !!!!

It plugs into the KittyDock....


Rockdoc

 

[adamasgem]

Date: 12/25/2006 11:45:28 AM
Author: RockDoc
RE : OGI Format

Gee Marty.... that''s easy.....


It''s a sub derivative called KLBSBasic... ( Kitty Litter Box Scanner Basic ) !!!!

It plugs into the KittyDock....


Rockdoc

All the output data quantized to FarceWare(TM) input standards, I believe

 

[Garry H (Cut Nut)]

Sergey converted Jonathans Ogi scan from binary stl

 

[adamasgem]

Date: 12/25/2006 2:12:33 PM
Author: Garry H (Cut Nut)
Sergey converted Jonathans Ogi scan from binary stl

OK, the STL, either in MeshWorks or Sergey''s conversion doesn''t match Jonathon''s OGI rendering.. Which is correct???? Or are both wrong...

 

[Serg]

Date: 12/25/2006 2:39:02 PM
Author: adamasgem

Date: 12/25/2006 2:12:33 PM
Author: Garry H (Cut Nut)
Sergey converted Jonathans Ogi scan from binary stl

OK, the STL, either in MeshWorks or Sergey''s conversion doesn''t match Jonathon''s OGI rendering.. Which is correct???? Or are both wrong...

Marty,

I Have sent Garry two models. One is simple conversion from stl, second is convex approximation.
Garry published second model, first is exactly in your post

 

[adamasgem]

Date: 12/26/2006 1:14:38 AM
Author: Serg

Date: 12/25/2006 2:39:02 PM
Author: adamasgem

Date: 12/25/2006 2:12:33 PM
Author: Garry H (Cut Nut)
Sergey converted Jonathans Ogi scan from binary stl

OK, the STL, either in MeshWorks or Sergey's conversion doesn't match Jonathon's OGI rendering.. Which is correct???? Or are both wrong...

Marty,

I Have sent Garry two models. One is simple conversion from stl, second is convex approximation.
Garry published second model, first is exactly in your post

I don't understand your use of the term "convex approximation".
The triangles on an STL file may be grouped (with common normals), and then the vectors making up the triangles sorted (and eliminated) to build the common facet boundary (speeds up ray tracing by reducing the number of "facets"). Is this what you mean???

Regardless, both models appear wrong because of the symmetrical "tits" at the girdle break facet junctions which I doubt exist (although they could if the girdle was faceted) and the lack of crown breaks (mains merged into breaks)

 

[Serg]

Marty,
See image of same model from DC without convex approximation

 

[adamasgem]

Date: 12/26/2006 10:53:24 AM
Author: Serg
Marty,
See image of same model from DC without convex approximation

Looks like the rendering from Meshworks with a overabundance of STL triangles..Still can''t see how Johnathons OGI rendering fits in. Maybe it is due to a problem in grouping or discerning common normals.. I''ve had that numerical problem when there are short STL sides to the triangle, and the facet normals in the STL file have numerically small differences.

 

[Garry H (Cut Nut)]

Date: 12/26/2006 9:31:31 AM
Author: adamasgem

Date: 12/26/2006 1:14:38 AM
Author: Serg

Date: 12/25/2006 2:39:02 PM
Author: adamasgem

Date: 12/25/2006 2:12:33 PM
Author: Garry H (Cut Nut)
Sergey converted Jonathans Ogi scan from binary stl

OK, the STL, either in MeshWorks or Sergey''s conversion doesn''t match Jonathon''s OGI rendering.. Which is correct???? Or are both wrong...

Marty,

I Have sent Garry two models. One is simple conversion from stl, second is convex approximation.
Garry published second model, first is exactly in your post

I don''t understand your use of the term ''convex approximation''.
The triangles on an STL file may be grouped (with common normals), and then the vectors making up the triangles sorted (and eliminated) to build the common facet boundary (speeds up ray tracing by reducing the number of ''facets''). Is this what you mean???

Regardless, both models appear wrong because of the symmetrical ''tits'' at the girdle break facet junctions which I doubt exist (although they could if the girdle was faceted) and the lack of crown breaks (mains merged into breaks)

I recieved your email on this Sergey. I am traveling on vacation and can recieve - but not send emails.

I also do not understand the differences and reasons for stl problems from Ogi scans

 

[adamasgem]

Date: 12/26/2006 7:01:40 PM
Author: Garry H (Cut Nut)

I recieved your email on this Sergey. I am traveling on vacation and can recieve - but not send emails.

I also do not understand the differences and reasons for stl problems from Ogi scans

I''m glad I''m not the only one who admits it

 

[Serg]

re:I also do not understand the differences and reasons for stl problems from Ogi scans

I do not see any problem with stl. I see problem with OGI model only.

About which problem are you speaking?

 

[adamasgem]

Date: 12/21/2006 9:57:29 AM
Author: adamasgem

Here are the links to the virtual facet ASET images versus tilt (5 degree increments) courtesy of Peter Yantzer of AGS Laboratory.
.
Thanks also to Leonid for uploading the large files...

The file naming conventions define the parameters..
Symmetrical..

Both have 53 Table size, 80% Lower Girdle facet length

Nominal Tolkowsky

40.75 pavilion angle 34.5 Crown

www.pricescope.com/uploads/p4075t53c345s50lg80-combine_lg.gif

40.4 pavilion angle 36.5 Crown Angle


www.pricescope.com/uploads/p404t53c365s50lg80-combined.gif



These ASET images show the regions where the virtual facet is collecting the light...

One has to realize that NO stone has ''perfect'' physical symmetry, nor can one ''really'' measure the stone, and that ANY small measurement error may propogate into a substantailly different rendering, ASET or phototreal, and by their vary nature, these analyses are qualitative...

EVEN physical devices, especially like a small Hearts and Arrows Viewer are limited, as relative size of the stone to the device (~1'' diameter in the H&A case) alters the input ray coloration (image) and that two IDENTICALLY cut stones of different sizes will present different images..

The larger the device, the smaller the contrast (color) cutoffs and the less sensitive the visual presentation is versus stone size..

One can only do the ''job'' consistently by software, and even then the limitations of the scanners come into play..

One small note for the community is that while in Israel I visited Sarin, and they have made great improvements in their scanner recognition software with regard to being able to ''accurately'' scan the EightStar and NewLine class of stones, and I believe the software upgrades will be distributed shortly.. I will be discussing some minor issues with them, and will be interested to see comparisons of the scans among various vendors on the same stone (Helium/OGI/Sarin {in alphabetical order]). More on this in a new thread..

Getting back on the original track for this thread, here is a comparable ASET images for the Tolkowsky nominal above with the pavilion rotated 22.5 degrees with respect to the crown. Again thanks to Peter Yanzter of AGS for running this simulation.

https://www.pricescope.com/uploads/tolk-primary-pav-rotated-22.gif

 

[adamasgem]

Date: 12/27/2006 2:16:39 AM
Author: Serg
re:I also do not understand the differences and reasons for stl problems from Ogi scans

I do not see any problem with stl. I see problem with OGI model only.

About which problem are you speaking?

Back to the secondary topic....

If you look at the OGI STL file, besides the abnormally large number of STL triangles, in particular the extension of the break facet junctions at the girdle plane beyond the girdle outline (shown in yellow on your expanded STL rendering). In my way of thinking the "model" comes first, and the STL file is generated from the "model", after each facet is defined.

 

[adamasgem]

Date: 12/27/2006 2:16:39 AM
Author: Serg
re:I also do not understand the differences and reasons for stl problems from Ogi scans

I do not see any problem with stl. I see problem with OGI model only.

About which problem are you speaking?

Sergey.. I'm having trouble decoding the OGI binary STL file.. I used the STL standard binary structure (with the 2 byte padding at the end of each triangle) and could discern 14342 triangles [from the second record](which is rediculous), but came up with a file error when I tried to combine triangles with common normals. Any suggestions???? Is each whole triangle in a separate record??

 

[adamasgem]

Date: 12/26/2006 10:53:24 AM
Author: Serg
Marty,
See image of same model from DC without convex approximation

Sergey I was able to read the OGI binary file and could only resolve it to the level of your picture (without convex approximation), which probably has to do with my assigning single precision data from the OGI STL file to double precision numbers for grouping of common normals... I don''t have a problem grouping other STL ascii type files into common facets, and I am using the same code for both, just the read of the normals and vertices is different. I''m perplexed.

What exactly do you mean by "convex approximation"

 

[adamasgem]

Date: 12/27/2006 11:23:54 AM
Author: adamasgem

Date: 12/26/2006 10:53:24 AM
Author: Serg
Marty,
See image of same model from DC without convex approximation

Sergey I was able to read the OGI binary file and could only resolve it to the level of your picture (without convex approximation), which probably has to do with my assigning single precision data from the OGI STL file to double precision numbers for grouping of common normals... I don''t have a problem grouping other STL ascii type files into common facets, and I am using the same code for both, just the read of the normals and vertices is different. I''m perplexed.

What exactly do you mean by ''convex approximation''

This is a profile of the OGI STL file.. I GUESS what you mean by "convex approximation" is that SOMEONE has to fix their OGI''s) concave faceting problem. Make you wonder how "accurate" their angles could be, and whether or not there was fudging done (and how much) to make it appear that they were getting a good scan, as in Jonathons OGI rendering of the same stone which generated the STL file in this thread.

I pity GIA (serves them right)... Maybe this is an example of why they had to go to FARCEWARE(TM) rounding "standards".

 

[JohnQuixote]

Date: 12/24/2006 4:07:42 PM
Author: Garry H (Cut Nut)

Some scanner companies attepmt to use their software to ''average'' out stone defects and make their models symetrical.

There is a cheat programmed into the algos that draws a straight line between high spots in the edge detection. If you want to see further proof run a stone with an indented natural on a flat facet.

Marty, one of the reasons GIA gives for rounding is, in fact, that some non-contact devices can''t overcome this kind of limitation, along with variable repeatability.

 

[Rhino]

Date: 12/24/2006 12:09:39 PM
Author: adamasgem

Date: 12/24/2006 12:02:53 PM
Author: Rhino
Perhaps Sergey can make the DC import binary .stl''s? Either that or I''ll give OGI a call and see if they can make a fix to export ascii.

There is more than that binary problem. Here is the OGI stl file you sent me imported into MeshWorks..

It DOESN''T give me any warm and fuzzy feeling regarding OGI, and is inconsistent with the rendering you posted..

Unfortunately, since it is in some standard form of STL binary that I don''t know the format of, I can''t help much..

LOL... me neither. Here is a graphic generated from that .stl file in a program called "Solid View" that imports every kind of .stl which is similar to what you posted.

I received an email yesterday from OGI and they are sending me an updated scanner/software of their latest/greatest so we''ll do a compare and see.

I''m wondering how it was able to generate and resolve all the facets plus their angles on their web viewer software. They''re pretty responsive to me so I''ll see what their answer is to that.

 

[strmrdr]

Date: 12/27/2006 1:40:49 PM
Author: JohnQuixote

Date: 12/24/2006 4:07:42 PM
Author: Garry H (Cut Nut)

Some scanner companies attepmt to use their software to ''average'' out stone defects and make their models symetrical.

There is a cheat programmed into the algos that draws a straight line between high spots in the edge detection. If you want to see further proof run a stone with an indented natural on a flat facet.

Marty, one of the reasons GIA gives for rounding is, in fact, that some non-contact devices can''t overcome this kind of limitation, along with variable repeatability.

yep thats why software updates are suspect.
they could just be guessing prettier instead of measuring better.
which it sounds like serg is saying is happening here.
running a different shape stone should help show if the fix is real.

 

[Rhino]

Date: 12/24/2006 4:07:42 PM
Author: Garry H (Cut Nut)

Date: 12/21/2006 8:11:23 PM
Author: Rhino
A peek to the future ...

You''ll note in this first screenshot taken within the OGI software itself it''s difficulty resolving the upper half facets becuase their angles are so so close to the actual crown mains. Stones like this are the hardest for a scanner to detect however OGI has pointed out to me that their scanner does indeed *see* these facets but the model in the current software isn''t showing them. More on this in the next graphic.

Some scanner companies attepmt to use their software to ''average'' out stone defects and make their models symetrical.

It adds a kind of '' surveyors loop closing arithmatic error ''.

What you showed was an excellent example where they get caught out Rhino.

It appears so.

 

[Rhino]

Date: 12/26/2006 12:02:33 PM
Author: adamasgem

Date: 12/26/2006 10:53:24 AM
Author: Serg
Marty,
See image of same model from DC without convex approximation

Looks like the rendering from Meshworks with a overabundance of STL triangles..Still can''t see how Johnathons OGI rendering fits in. Maybe it is due to a problem in grouping or discerning common normals.. I''ve had that numerical problem when there are short STL sides to the triangle, and the facet normals in the STL file have numerically small differences.

I just sent an email to OGI with both the .stl file and also the .ogi file (which showed a more perfect model and resolved all the facets) asking how they came up with the results on hte .ogi file. I''ll let ya know how they answer.