OpenSCAD

Nabble removed Mailing-list integration from the Forum.
This killed the Forum. This is now an ARCHIVE.
It is likely Nabble will shutdown in the future.

So basically the Forum is now out of date, we are looking into migrating the history.

OpenSCAD support is now provided by the Mailing List.
See the first pinned post here for instructions on subscribing to the mailing list.

Handle float wonk in git-tracked STLs

Classic

List

Threaded

7 messages Options

tjhowse

Handle float wonk in git-tracked STLs

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]

nophead

Re: Handle float wonk in git-tracked STLs

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]

JordanBrown

Re: Handle float wonk in git-tracked STLs

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]

nophead

Re: Handle float wonk in git-tracked STLs

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]

JordanBrown

Re: Handle float wonk in git-tracked STLs

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

Re: Handle float wonk in git-tracked STLs

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

tjhowse

Re: Handle float wonk in git-tracked STLs

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

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]

So basically the Forum is now out of date, we are looking into migrating the history.

OpenSCAD support is now provided by the Mailing List. See the first pinned post here for instructions on subscribing to the mailing list.

Handle float wonk in git-tracked STLs

Handle float wonk in git-tracked STLs

Re: Handle float wonk in git-tracked STLs

Re: Handle float wonk in git-tracked STLs

Re: Handle float wonk in git-tracked STLs

Re: Handle float wonk in git-tracked STLs

Re: Handle float wonk in git-tracked STLs

Re: Handle float wonk in git-tracked STLs

OpenSCAD support is now provided by the Mailing List.
See the first pinned post here for instructions on subscribing to the mailing list.