Lucas,

Here you have a broader set of tests with void sets and surprising results:

--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17707.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

On Wed, Jun 15, 2016 at 09:14:09PM -0400, doug moen wrote:

The thing is: What costs time? The evaluation until you get there, or
the "keep going"?

Yesterday I spent an hour gathering the dependencies of a software
package. I would run "./configure" it would spend three minutes
checking for header files, and then it would say: Can't find XXXX and
bomb out.

So, normally my strategy is to fix the first error (or occasionally a
random error) and try again. But if it works like yesterday where the
wait until the error occurs I'll quickly switch to fixing ALL errors
before I try again.

For openSCAD as I know it, the "ignore undefined modules" strategy has
its merits. But a bigger "warning: ignored 3 undefined modules" would
IMHO be better...

Roger. 

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Roger said:

You raise a good point.

OpenSCAD has an evaluation phase (which generates the CSG tree), then a
rendering phase (which generates the mesh).

Normally, the evaluation phase is quick (milliseconds). This is the phase
where undefined modules are detected. Since there's normally no wait, I
want this phase to abort on first error and highlight in the text editor
the subexpression where the error occurred, because that would be the most
productive way for me to fix errors. That's what works for me. If other
people disagree, maybe this should be configurable?

The rendering phase is slow, and takes minutes or hours for any serious
model. During this phase, it would make sense to print informative error
messages and keep going, so that you can fix all the errors in a batch.
Unfortunately, CGAL assertion messages don't give you helpful information
that points back at the location in the source where the error occurred.
This is something that I think may improve in the future, based on active
pull requests.

Now, there is pressure from some parts of the community to support
geometric evaluation during the evaluation phase. (Recently, a request for
a boolean function to test if two shapes intersect, but there's a long
history of similar requests.) And, there are other parts of the community
who push back on this, and uphold the benefits of a fast evaluation phase
and fast preview. If we do go in the direction of making OpenSCAD more
powerful, at the expensive of long evaluation times, then the tradeoff
changes, and maybe abort on first error starts to make less sense.

The goal is to provide a productive workflow. Since we have a fully
integrated system with our own GUI and our own evaluator, we have the
ability to make this work very nicely. I would like the ability to jump
into the editor at the error location the instant an error occurs so that I
can fix the bug, regardless of whether evaluation continues past that
point. If evaluation does continue, then a button to advance to the next
error would be desirable.

On 16 June 2016 at 00:41, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

I think querying the geometry during evaluation and the attendant slow down
is fine as long as it only happens when the user explicitly invokes it. It
is no worse than the current situation with render(). Those of us who don't
need it would still get a fast preview.

On 16 June 2016 at 14:48, doug moen doug@moens.org wrote:

I agree, that OpenSCAD has no explicit definition of a void shape, like
'undef'. This might lead to some unclearness in understanding, what the
language actually does in some situations, without probing it. And I agree
that this is the region, where a language might have to be changed with the
risk of breaking legacy code - latest when the deficiency starts to get a
problem.

But is it a problem right now?

Having programmed with about 30 different programming languages multiplied
by an uncounted number of new versions and updates in my life, I never got
very far by just reading the reference or using my understanding of math,
especially when abstract operations solely defined for real values are in
play, but some finite number representations are being used. Minkowski
definitely falls into that category.

"Offside is, when the referee whistles". The idiosyncrasies of a language
are mostly a matter of taste AND of compromises that have to be made.

E.g. Would you want your cube to vanish in the first frame in an animation
like that?

I wouldn't. With your understanding, you would have to use some IF-construct
to sort out the empy result. But how would you do that? What about the value
0? Here it is again. Isn't it more a matter of something being smaler than
some epsilon? So, you wanna test against some epsilon, which is an internal
constant, that might chance with every release? You will never get a defined
result with this approach.
Anyway you put it, it has to be probed.

BTW: I would never use a minkowski() to generate a void result. Void results
are not desired in rendering, as they only cost time.

OpenSCAD's 'binary' operators operate over a set of shapes, which may have
n>=0 elements. Thus they are NOT binary operators as you are used to, but
some interpretation for their application on a batch of operands. Should
they be named differently for that? Why trying to be more Catholic than the
pope?

I would argue for a more instant mechanism to interactively stop F5 and F6
rendering, but never to convert warnings into an error. Is this also a
matter of taste? Other programming languages use customizable priority
levels to convert warnings into errors. Are we this far?

Before any of this will go into the language, many other by far more
important features have to be tackled.
To have functions for querying boundingboxes and polygons/polyhedra of
shapes are the most important ones. Also colors should not get lost on F6
...

Being able to play with a NULL more or less, nothing is gained for practical
use.

--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17714.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I thought about degenerate shapes some more.

Mathematically, a degenerate shape is one with zero volume. There is an
infinite family of degenerate 3D shapes: 0D points, 1D lines, 2D surfaces,
plus the empty set which contains no points at all. Mathematically,
operations like minkowski sum and convex hull behave differently depending
on what kind of degenerate shape is passed.

Pragmatically, it's different. OpenSCAD can't represent arbitrary 3D
shapes, only polyhedra. Degenerate shapes are a problem. Internally, we use
two different representations. With the mesh representation, a well formed
mesh must not contain any triangles with zero area. With the Nef Polyhedron
representation, AFAIK there is only one degenerate Nef Polyhedron (the
empty set), and not an infinite family.

So in practice, I think OpenSCAD can only have 1 degenerate shape, which we
should treat as the empty set. So union() {}, cube(0), cube([10,0,0]) and
others should all be treated the same way, as the unique degenerate shape.

Minkowski sum treats the empty set as the zero element and the point
[0,0,0] as the identity element, but we can have only one degenerate shape,
so we can't implement these semantics exactly. I think our unique
degenerate shape should be consistently treated as the empty set, so we
don't support an identity element for minkowski sum, only a zero element.

So that means, if you pass the degenerate shape as an argument to
minkowski, then I think the result should be the degenerate shape. It's
like multiplying a number by zero, the result is zero.

Right now, it appears that degenerate shapes aren't treated consistently.
Minkowski treats the void as its identity element, ie as [0,0,0], while
other operations I tested treat it as the empty set.

But, I just read Parkinbot's analysis, and I think he makes a good argument
with this example:

Since we only get to have one degenerate shape, we get to choose how it
works for each operation.

On 15 June 2016 at 20:13, Lucas Vinicius Hartmann lucas.hartmann@gmail.com
wrote:

Parkinbot said:

No, I wouldn't want the cube to vanish. The mathematically correct result
at $t=0 is that you just get a cube, which is exactly what happens in our
implementation.

It's no coincidence that "the mathematically correct result" is the same as
what you naturally expect to happen. In this case, "scale(0) sphere()"
should mathematically produce a degenerate solid, the point [0,0,0], which
is the identity element for minkowski, so you get a cube. And that's what
you actually get in practice.

Unfortunately, OpenSCAD doesn't produce the correct result all the time,
and it's hard to predict what will work and what will fail.

For example, this produces the correct result:

But this produce an incorrect result at $t=0:

It looks like the two versions should produce the same result, but they
don't. The situation with degenerate solids is more complicated than what I
thought. In the first version, "translate([20,0,0]) scale(0) cube(10)"
should produce a degenerate solid with a point at [20,0,0], and that's
apparently what happens, because the output is correct: the sphere is
centered at [20,0,0].

If I render
translate([20,0,0]) scale($t) cube(10);
then it says:

Top level object is a 3D object:

Facets: 6

And if I export this as STL, then I get an empty STL file (no triangles).

So that's good. It's the "mathematically correct" result.

In my previous post, I said that OpenSCAD can't represent an infinite
family of degenerate solids, therefore we can't make minkowski work
correctly. But my experiment shows that we do have a proper representation
for different kinds of degenerate solids, and minkowski does work
correctly, if you know how to work around the bugs.

I tried another experiment. This one is to construct the convex hull of two
different degenerate solids, to make a square based pyramid:

hull() {

translate([0,0,10]) scale(0) cube(); // apex of pyramid

cube([10,10,0], center=true); // base of pyramid

}

Unfortunately, this creates a scary popup error dialog, and then the render
hangs:

A critical error was caught. The application may have become unstable:

CGAL ERROR: precondition violation!

Expr: point2_it != points.end()

File:
/Users/kintel/code/OpenSCAD/openscad/../libraries/install/include/CGAL/convex_hull_3.h

Line: 922

Explanation: All points are equal; cannot construct polyhedron.

On 16 June 2016 at 10:19, Parkinbot rudolf@parkinbot.com wrote:

Rudolf,

You raised good points but I will keep mine about Minkowski. The example you
have shown of a vanishing cube is idiosyncratic but for other reasons. I
would expect that

       scale(0) sphere;

to be a point, the origin, and not a void set.

In Mathematics, you have a non-void set by doing a Minkowski sum of a point
and a non-void set. I thought we have no way in OpenSCAD to do a Minkowski
sum of a set with only a point or a line segment or a 2D shape due to the
simple fact that we can't express such sets or mix 2D shapes with 3D shapes
in OpenSCAD operations. However, we can at least in Minkowski operations.

And that is not idiosyncratic. It does exactly what I would expect. The
intersection is not void, it is a square that shrinks to the origin when
$t=0. The scaled sphere should do the same.

BTW, the above "technique" may be very usefull for rounding only some edges
of a solid.

There is much more complexities behind the scene... :)

--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17717.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

For me this is all a lot of speculations about internal representations. We
know that F5 translates to CSG and rendering is done in graphics
hardware/driver only, which I guess will be using its own NULLs.

As long as I can't evalute a shape in the sense of:

v = vertices(MyShape());
f = facesertices(MyShape());

everything can be in the black box.

Look at this: You can F5 it

and obviously get a "Normalized CSG tree has 1 elements". And CSG Tree Dump
shows:

You even can F6 it and export it to STL. But there you find:

So where is the math point of view?

--
View this message in context: http://forum.openscad.org/Evaluating-imported-STL-s-tp17682p17721.html
Sent from the OpenSCAD mailing list archive at Nabble.com.