Handle float wonk in git-tracked STLs

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Handle float wonk in git-tracked STLs

tjhowse
I've got a little project in which I have a SCAD file and all of the STLs generated from that SCAD checked into a git repo. I include the STLs so people unfamiliar with OpenSCAD can still make use of the STLs directly.

I have a script that re-generates the STLs from the SCAD, but the float non-determinism in the meshes means I must manually pick and choose the meaningfully different STLs to include in a commit alongside the SCAD changes, and discard the changes to the STLs that weren't affected by the change except for float rounding changes and/or vertex ordering.

Has anyone solved this problem? It's not a big deal - just a minor annoyance.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Handle float wonk in git-tracked STLs

nophead
I fix it by post processing all my STLs with this Python script: https://github.com/nophead/NopSCADlib/blob/master/scripts/c14n_stl.py

On Mon, 7 Jun 2021 at 04:50, tjhowse <[hidden email]> wrote:
I've got a little project in which I have a SCAD file and all of the STLs generated from that SCAD checked into a git repo. I include the STLs so people unfamiliar with OpenSCAD can still make use of the STLs directly.

I have a script that re-generates the STLs from the SCAD, but the float non-determinism in the meshes means I must manually pick and choose the meaningfully different STLs to include in a commit alongside the SCAD changes, and discard the changes to the STLs that weren't affected by the change except for float rounding changes and/or vertex ordering.

Has anyone solved this problem? It's not a big deal - just a minor annoyance.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Handle float wonk in git-tracked STLs

JordanBrown
In reply to this post by tjhowse
Floating point isn't non-deterministic.  It's difficult for mere humans to predict the results of non-trivial operations out to the last decimal place, but if you run the same calculation twice you should get *exactly* the same answer.  (Note, though:  different *implementations* might produce slightly different results.)

But:  why not just commit the new versions of the files?  Github doesn't charge per byte-of-change; it seems like you are spending effort to to reduce a cost that is almost zero.


_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Handle float wonk in git-tracked STLs

nophead
OpenSCAD STL export is non-deterministic, you don't get the same results for exactly the same model, nothing to do with floating point. The order of vertices and facets depends on the machine addresses, so a change of machine or just some extra code that has no effect on the STL causes its order to change, making github think it has changed when it hasn't.

It is useful to know when your model has changed and when it hasn't so you catch unintended changes and also no if you need to reprint it.

On Mon, 7 Jun 2021 at 21:11, Jordan Brown <[hidden email]> wrote:
Floating point isn't non-deterministic.  It's difficult for mere humans to predict the results of non-trivial operations out to the last decimal place, but if you run the same calculation twice you should get *exactly* the same answer.  (Note, though:  different *implementations* might produce slightly different results.)

But:  why not just commit the new versions of the files?  Github doesn't charge per byte-of-change; it seems like you are spending effort to to reduce a cost that is almost zero.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Handle float wonk in git-tracked STLs

JordanBrown
On 6/7/2021 1:16 PM, nop head wrote:
OpenSCAD STL export is non-deterministic, you don't get the same results for exactly the same model, nothing to do with floating point. The order of vertices and facets depends on the machine addresses, so a change of machine or just some extra code that has no effect on the STL causes its order to change, making github think it has changed when it hasn't.

Ah.  Good information.  Yeah, that's pretty wrong.  It sounds like even two runs in sequence could produce subtly different output.


_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Handle float wonk in git-tracked STLs

tp3
On 07.06.21 23:06, Jordan Brown wrote:
> Ah.  Good information.  Yeah, that's pretty wrong.  It sounds
> like even two runs in sequence could produce subtly different
> output.

The infrastructure for that, based on nopheads script, is already
prepared. Only 3MF uses it so far, STL still needs to be converted
to use it.

https://github.com/openscad/openscad/blob/master/src/export.h#L124-L146

ciao,
  Torsten.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Handle float wonk in git-tracked STLs

tjhowse

On Tue, 8 Jun 2021 at 09:44, Torsten Paul <[hidden email]> wrote:
On 07.06.21 23:06, Jordan Brown wrote:
> Ah.  Good information.  Yeah, that's pretty wrong.  It sounds
> like even two runs in sequence could produce subtly different
> output.

The infrastructure for that, based on nopheads script, is already
prepared. Only 3MF uses it so far, STL still needs to be converted
to use it.

https://github.com/openscad/openscad/blob/master/src/export.h#L124-L146

ciao,
  Torsten.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]