discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Handle float wonk in git-tracked STLs

T
tjhowse
Mon, Jun 7, 2021 3:49 AM

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.

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.
NH
nop head
Mon, Jun 7, 2021 8:48 AM

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 tjhowse@gmail.com 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 discuss-leave@lists.openscad.org

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 <tjhowse@gmail.com> 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 discuss-leave@lists.openscad.org >
JB
Jordan Brown
Mon, Jun 7, 2021 6:54 PM

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.

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.
NH
nop head
Mon, Jun 7, 2021 8:16 PM

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 openscad@jordan.maileater.net
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 discuss-leave@lists.openscad.org

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 <openscad@jordan.maileater.net> 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 discuss-leave@lists.openscad.org >
JB
Jordan Brown
Mon, Jun 7, 2021 9:06 PM

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.

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.
TP
Torsten Paul
Mon, Jun 7, 2021 11:44 PM

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.

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.
T
tjhowse
Thu, Jun 10, 2021 6:16 AM

Something like this? https://github.com/openscad/openscad/pull/3806

On Tue, 8 Jun 2021 at 09:44, Torsten Paul Torsten.Paul@gmx.de 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 discuss-leave@lists.openscad.org

Something like this? https://github.com/openscad/openscad/pull/3806 On Tue, 8 Jun 2021 at 09:44, Torsten Paul <Torsten.Paul@gmx.de> 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 discuss-leave@lists.openscad.org >