Clarifying behaviors
kintel wrote
On Nov 18, 2016, at 13:47, Ronaldo <
rcmpersiano@
> wrote:
I will claim that rejecting the union of two cubes with just one vertex
in common is a bug.
I’d love to be able to robustly process such objects, at the very least
since they can be valuable partial results.
However, our path into CGAL uses software components with a strict
manifold requirement, so this is no trivial to implement.
So no, it’s not a bug, it’s a missing feature. It needs resources to
implement properly.
Sorry, Kintel, may be I had not been clear enough. I am not defending that
two cubes meeting in a vertex should be acceptable. I am saying that the
topology should be consistent with the geometry. Therefore, if two vertices
in the vertex list of a polyhedron definition have the same coordinates
(geometrically equal) they should be topologically equal too. If this rule
fails in polyhedron definitions they should fail everywhere.
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p19225.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Nov 18, 2016, at 15:57, Ronaldo rcmpersiano@gmail.com wrote:
Sorry, Kintel, may be I had not been clear enough. I am not defending that
two cubes meeting in a vertex should be acceptable. I am saying that the
topology should be consistent with the geometry. Therefore, if two vertices
in the vertex list of a polyhedron definition have the same coordinates
(geometrically equal) they should be topologically equal too. If this rule
fails in polyhedron definitions they should fail everywhere.
Thanks for the clarification. Geometrically equal vertices are always topologically equal today, also for polyhedron definitions.
There was a bug related to this, which triggered in some rare cases, which I fixed yesterday (as discussed in another thread).
Some file formats require vertices to be split up in order to attach certain attributes to them. This may include meta data to be able to identify which closed volume that vertex is part of. We may need to both read, preserve and write such information if we want to keep topology unambiguous. These are potential future enhancements though.
-Marius
It is not just behaviour that is somewhat grey, syntax is not very clear in
the wiki.
I had considered trying to document it in BNF, specifically I like EBNF
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form .
Thoughts?
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p19231.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
So let's put this equivalence into the wiki. The following two polyhedra are
identical and will be forever:
x = [[0,0,0], [0,10,0], [5,5,0], [2,2,2]];
polyhedron(x, [[0,2,1], [0,1,3], [1,2,3], [0,3,2]] );
y = [[0,0,0],[5,5,0], [0,10,0],
[0,0,0],[5,5,0], [0,10,0],
[0,10,0], [5,5,0],[2,2,2],
[0,0,0],[2,2,2],[5,5,0],
[0,0,0], [2,2,2], [0,10,0]];
polyhedron(y, [[0,1,2], [3,4,5], [6,7,8], [9,10,11]] );
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p19235.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 11/19/2016 01:54 AM, Parkinbot wrote:
So let's put this equivalence into the wiki. The following two
polyhedra are identical and will be forever:
I guess the better solution would be an actual test case that
shows things break just after some change.
That also needs a more specific definition of "identical" (e.g.
after sorting triangles? identical STL export? AMF? 3MF?).
ciao,
Torsten.
On Nov 18, 2016, at 18:35, MichaelAtOz oz.at.michael@gmail.com wrote:
I had considered trying to document it in BNF, specifically I like EBNF
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form .
Giles started on a BNF a good while ago:
https://github.com/GilesBathgate/RapCAD/blob/master/doc/openscad.bnf
I also played around with railroad diagrams to make it easier to consume by humans (this is for a slight refactoring of the openscad grammar):
http://files.openscad.org/grammar.xhtml
This only documents the grammar, not the semantics of how it’s interpreted.
-Marius
identical STL export?
Currently openscad STL files have non-deterministic order because IIRC some
part of the software uses machine addresses to order vertices. If you
change any of the source code or compile it on another machine it can make
the facet and vertex order change even when the object is identical.
I use this script to make the order deterministic:
https://github.com/nophead/Mendel90/blob/master/c14n_stl.py. Even then
there are numerical differences in the vertex coordinates between openscad
versions.
On 19 November 2016 at 04:56, Marius Kintel marius@kintel.net wrote:
On Nov 18, 2016, at 18:35, MichaelAtOz oz.at.michael@gmail.com wrote:
I had considered trying to document it in BNF, specifically I like EBNF
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form .
Giles started on a BNF a good while ago:
https://github.com/GilesBathgate/RapCAD/blob/master/doc/openscad.bnf
I also played around with railroad diagrams to make it easier to consume
by humans (this is for a slight refactoring of the openscad grammar):
http://files.openscad.org/grammar.xhtml
This only documents the grammar, not the semantics of how it’s interpreted.
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Nov 19, 2016, at 05:29, nop head nop.head@gmail.com wrote:
I use this script to make the order deterministic: https://github.com/nophead/Mendel90/blob/master/c14n_stl.py. Even then there are numerical differences in the vertex coordinates between openscad versions.
Note that this also won’t provide identical output across compilers, as floating point rounding will be performed differently.
See e.g. http://martinwguy.co.uk/crunch/test/tybor/tbin2dec.c
-Marius
I would like to resume this:
Parkinbot wrote
So let's put this equivalence into the wiki. The following two polyhedra
are identical and will be forever:
x = [[0,0,0], [0,10,0], [5,5,0], [2,2,2]];
polyhedron(x, [[0,2,1], [0,1,3], [1,2,3], [0,3,2]] );
y = [[0,0,0],[5,5,0], [0,10,0],
[0,0,0],[5,5,0], [0,10,0],
[0,10,0], [5,5,0],[2,2,2],
[0,0,0],[2,2,2],[5,5,0],
[0,0,0], [2,2,2], [0,10,0]];
polyhedron(y, [[0,1,2], [3,4,5], [6,7,8], [9,10,11]] );
I may do an addition to the Manual but I need beforehand Kintel's agreement.
I understand that equivalence may be ambiguous or too strong but we may say
that both models above express the same geometry and topology eventually
with different internal and external representations.
--
View this message in context: http://forum.openscad.org/Clarifying-behaviors-tp18492p19362.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Von: Ronaldo rcmpersiano@gmail.com
I may do an addition to the Manual but I need
beforehand Kintel's agreement.
I understand that equivalence may be ambiguous
or too strong but we may say that both models
above express the same geometry and topology eventually
with different internal and external representations.
As said before, having this only in the Manual is not
really helpful. It might break without anybody noticing
for a long time after which it's hard to impossible to
change behavior back.
The only way to prevent that, is to have an actual
test case added to our test suite after the details
are clear.
Of cause having an additional note in the Manual would
be good.
If this clarification is much desired, the best
strategy is to create an issue on github as it's
not as easily lost as some mails/forum entries.
ciao,
Torsten.