Linear extrude SVG with scale determined by math function?
On 02/02/2022 09:44, Rogier Wolff wrote:
I actually think they should be able to keep openscad units as
"1mm" and then design their pump.
Why would they do that? That would be worse than designing a house, and
dimensioning it in fractions of a mile. Openscad is unitless, so you can
assign whatever units you wish. If the pump is part of a larger system,
I guess it would be sensible to have various scales for different details.
Best wishes,
Ray
I'm with Ray on this point. You should choose the units that match
the scale of your object. The reason we have prefixes in SI is so you
don't have to deal with carrying around an exponent. You can say
micrometers instead of 10^-6 meters. The situation where you are in
trouble if you're designing a meter scale object but somehow care
about micrometers.
With regards to OpenSCAD, I believe the grid size is 2^-20 for
polyhedron and 2^-11 for operations in 2D (the ClipperLib for 2d ops
uses integers, so everything is scaled by 2048 and rounded and then
unscaled).
On Wed, Feb 2, 2022 at 4:44 AM Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Tue, Feb 01, 2022 at 05:59:51PM +0000, Jordan Brown wrote:
� I think the grid is several orders of magnitude too large,
that at 10^-6 you are far more likely to have points inappropriately
The thing is that if the grid is say one order-of-magnitude larger
than the LSB of floating point numbers, then WHEN there is an
off-by-one-LSB error, there is a 1:10 chance they will be snapped to
different points. To reduce the chances of that happening, there must
be at least several orders-of-magnitude between the floating point
resolution and the grid.
merged than to miss points that should be merged. Of course features
at 10^-6 are too small to care about in real life,
Real-life for you seems to mean: 3D-printable with the 3Dprinter that
you have.
Research groups are working on miniaturizing stuff and finding ways to
produce them. What if they want to make a miniature pump at micrometer
scale? I actually think they should be able to keep openscad units as
"1mm" and then design their pump. That will fail if there is an
invisible grid at the micrometers. Oh, are you saying 10^-6 mm ? Then
the grid would be at the nanometer scale. There is also research going
on to make things at that scale.
You've mentioned your house-model at 25.4:1 modeled in
openscad. Openscad is actually unaware of what size 1 unit is. So are
STLs. It is the slicers that assume (until told otherwise) 1 unit in
the STL = 1mm.
So actually you have a 1:1 scale model as long as you think of
openscad units as 1" for that file.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
[ Combining replies to a few different people., and changed the subject
since this is no longer really about linear extruding SVGs. ]
Adrian said:
With regards to OpenSCAD, I believe the grid size is 2^-20 for
polyhedron and 2^-11 for operations in 2D (the ClipperLib for 2d ops
uses integers, so everything is scaled by 2048 and rounded and then
unscaled).
eps = 1e-6;
cube(1);
translate([1+eps, 1+eps, 0]) cube(1);
is considered non-manifold.
Further experiments show that for the model above, the dividing line is
5e-6. eps=5e-6 is OK; 4.99999e-6 is not.
The above is from 2021.01. Strangely, this is not a problem in my build
from September 2021. I think it's got a new version of CGAL; perhaps
that's a factor.
Roger said:
The thing is that if the grid is say one order-of-magnitude larger
than the LSB of floating point numbers, then WHEN there is an
off-by-one-LSB error, there is a 1:10 chance they will be snapped to
different points. To reduce the chances of that happening, there must
be at least several orders-of-magnitude between the floating point
resolution and the grid.
The LSB is down around 10^-16. There are ten orders of magnitude
between 10^-6 and 10^-16. We don't have to push it all the way down to
10^-15.
But you raise an important concept: probability. If you're doing
simplistic snapping to a grid, there will always be a probability that
two points that are supposed to be the same will end up on different
sides of the dividing point. Indeed, if everything is random that will
happen at a frequency related to the size of the grid as compared to the
LSB. But not everything is random. In most models, some numbers show
up more frequently than others. Integers are really popular, as are
small fractions... like ½. I'm not sure what the effect is on the grid
behavior, but I bet that there is an effect.
Research groups are working on miniaturizing stuff and finding ways
to produce them. What if they want to make a miniature pump at
micrometer scale? I actually think they should be able to keep
openscad units as "1mm" and then design their pump. That will fail if
there is an invisible grid at the micrometers.
There is an invisible grid at 10^-6 units, and they will fail... today.
eps = 1;
size = 1e-6;
cube(size);
translate([size+eps, size+eps, 0]) cube(size);
(Note that where the previous example was two one-unit cubes separated
by a tiny amount, this is two tiny cubes separated by one unit. Why two
cubes? Because CGAL doesn't get involved unless you have two objects.)
This yields "WARNING: No top level geometry to render".
The truly right answer, if you're going to round, is probably to round
at N significant figures, rather than at an absolute size.
You've mentioned your house-model at 25.4:1 modeled in openscad.
Openscad is actually unaware of what size 1 unit is. So are STLs. It
is the slicers that assume (until told otherwise) 1 unit in the STL =
1mm.
So actually you have a 1:1 scale model as long as you think of
openscad units as 1" for that file.
Sure, but the point remains: mathematically, if an object is manifold
at one scale, then it is manifold at any other scale. With OpenSCAD and
my slicer at the time, if I took my OK-at-one-scale model and scaled it
down by 25.4 in OpenSCAD, it became not-OK. (I never deeply analyzed
the problem, so I don't know whether the problem was at the grid or
something to do with STL. It was a long time ago and I don't remember
the details. It was close enough that I was able to print something
recognizable as a model of the model.)
The problem I have with the grid is that if you have two curved surfaces
meeting at an angle it is impossible to guarantee the points along the
intersection line are not arbitrarily close to another point. So it is
random whether the result is manifold or not after the grid snap.
On Wed, 2 Feb 2022 at 17:02, Jordan Brown openscad@jordan.maileater.net
wrote:
[ Combining replies to a few different people., and changed the subject
since this is no longer really about linear extruding SVGs. ]
Adrian said:
With regards to OpenSCAD, I believe the grid size is 2^-20 for polyhedron
and 2^-11 for operations in 2D (the ClipperLib for 2d ops uses integers, so
everything is scaled by 2048 and rounded and then unscaled).
eps = 1e-6;
cube(1);
translate([1+eps, 1+eps, 0]) cube(1);
is considered non-manifold.
Further experiments show that for the model above, the dividing line is
5e-6. eps=5e-6 is OK; 4.99999e-6 is not.
The above is from 2021.01. Strangely, this is not a problem in my build
from September 2021. I think it's got a new version of CGAL; perhaps
that's a factor.
Roger said:
The thing is that if the grid is say one order-of-magnitude larger than
the LSB of floating point numbers, then WHEN there is an off-by-one-LSB
error, there is a 1:10 chance they will be snapped to different points. To
reduce the chances of that happening, there must be at least several
orders-of-magnitude between the floating point resolution and the grid.
The LSB is down around 10^-16. There are ten orders of magnitude between
10^-6 and 10^-16. We don't have to push it all the way down to 10^-15.
But you raise an important concept: probability. If you're doing
simplistic snapping to a grid, there will always be a probability that two
points that are supposed to be the same will end up on different sides of
the dividing point. Indeed, if everything is random that will happen at a
frequency related to the size of the grid as compared to the LSB. But not
everything is random. In most models, some numbers show up more frequently
than others. Integers are really popular, as are small fractions... like
½. I'm not sure what the effect is on the grid behavior, but I bet that
there is an effect.
Research groups are working on miniaturizing stuff and finding ways to
produce them. What if they want to make a miniature pump at micrometer
scale? I actually think they should be able to keep openscad units as "1mm"
and then design their pump. That will fail if there is an invisible grid at
the micrometers.
There is an invisible grid at 10^-6 units, and they will fail... today.
eps = 1;
size = 1e-6;
cube(size);
translate([size+eps, size+eps, 0]) cube(size);
(Note that where the previous example was two one-unit cubes separated by
a tiny amount, this is two tiny cubes separated by one unit. Why two
cubes? Because CGAL doesn't get involved unless you have two objects.)
This yields "WARNING: No top level geometry to render".
The truly right answer, if you're going to round, is probably to round at
N significant figures, rather than at an absolute size.
You've mentioned your house-model at 25.4:1 modeled in openscad. Openscad
is actually unaware of what size 1 unit is. So are STLs. It is the slicers
that assume (until told otherwise) 1 unit in the STL = 1mm.
So actually you have a 1:1 scale model as long as you think of openscad
units as 1" for that file.
Sure, but the point remains: mathematically, if an object is manifold at
one scale, then it is manifold at any other scale. With OpenSCAD and my
slicer at the time, if I took my OK-at-one-scale model and scaled it down
by 25.4 in OpenSCAD, it became not-OK. (I never deeply analyzed the
problem, so I don't know whether the problem was at the grid or something
to do with STL. It was a long time ago and I don't remember the details.
It was close enough that I was able to print something recognizable as a
model of the model.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 2/2/2022 9:32 AM, nop head wrote:
The problem I have with the grid is that if you have two curved
surfaces meeting at an angle it is impossible to guarantee the points
along the intersection line are not arbitrarily close to
another point. So it is random whether the result is manifold or not
after the grid snap.
Yes... the bad behavior goes both ways. If the grid is too large,
points that are supposed to be distinct can be merged. If the grid is
too small, points that are supposed to be the same can be separated.
I tend to think that the current grid is too large, that accidentally
merging distinct points happens too much and that points that are
supposed to be the same get separated too rarely. But I have no
experience with other settings and would be interested to experiment.
(Really I think that the whole notion of manifoldness shouldn't come
into the picture; it has no practical relevance at any scale.)
On Wed, Feb 02, 2022 at 05:01:35PM +0000, Jordan Brown wrote:
But not everything is random.� In most models, some numbers show
up more frequently than others.
Yes, the "everything is random" assumption is a "worst case"
assumption. Real life is often better than the worst case situation.
Your "significant digits" suggestion: I don't think that can work. In
your example, you moved an "eps" sized cube to 1 unit. Should the unit
be used for scaling the grid or the eps? The problems arose because
the grid was eps-sized. (i.e. based off the unit).
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On 2/3/2022 1:03 AM, Rogier Wolff wrote:
Yes, the "everything is random" assumption is a "worst case"
assumption. Real life is often better than the worst case situation.
And sometimes real life is worse than random.
Your "significant digits" suggestion: I don't think that can work. In
your example, you moved an "eps" sized cube to 1 unit. Should the unit
be used for scaling the grid or the eps? The problems arose because
the grid was eps-sized. (i.e. based off the unit).
I'm not sure that I entirely follow what you're saying, but in a sig-fig
based grid the grid would in essence be logarithmic. The grid units
would be very small near the origin, and would get larger as you get
further away from the origin. An object that can be precisely
represented at the origin might not be representable far away from the
origin. (Exactly as floating point numbers themselves behave.)
On Fri, Feb 04, 2022 at 01:29:26AM +0000, Jordan Brown wrote:
I'm not sure that I entirely follow what you're saying, but in a sig-fig
based grid the grid would in essence be logarithmic. The grid units
would be very small near the origin, and would get larger as you get
further away from the origin. An object that can be precisely
represented at the origin might not be representable far away from the
origin. (Exactly as floating point numbers themselves behave.)
The thing is... you don't want surprises. If I make an object, verify
it works (generates valid STL?) and then use it as a module in a
bigger project. Then a translation will "change the grid" and can
possibly introduce problems that don't exist when the object is at the
origin...
This would be a "hard-to-debug" problem. The "programming errors" that
give an "error on line 1234" are "easy". The difficult ones are the
ones that dissappear once you isolate them.
In programming using two variables test_a and test_A would cause
hard-to-find bugs. The compiler doesn't warn when you use the wrong
one, and they read the same to a human.
In electronics using too little decoupling causes hard-to-find
bugs. It often works, but just every once in a while, the electronics
will "make a mistake". A 0 will be read as a 1, or a memory cell will
flip. This can happen once in every 100 cases: meaning "easy to find,
can reproduce in less than a second" to "happens every day or so" ->
enough to be very annoying, but rare enough to be VERY time consuming
to debug.
The lesson is: try to structure things in such a way that the
hard-to-find mistakes are hard-to-make.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
On 2/4/2022 1:44 AM, Rogier Wolff wrote:
The thing is... you don't want surprises. If I make an object, verify
it works (generates valid STL?) and then use it as a module in a
bigger project. Then a translation will "change the grid" and can
possibly introduce problems that don't exist when the object is at the
origin...
Indeed, though that can happen now with a fixed grid, especially if you
rotate the object.
The lesson is: try to structure things in such a way that the
hard-to-find mistakes are hard-to-make.
Yes.
Thank you Jordan
I've been working on making bits for my pipes. (I bite through them.)
I take a series of measurements of the Y and Z axes along the X axis and
smooth them using bezier curves.
I did a brute force extrusion which took 49 minutes to render. Using
your variable_extrude module it takes 14 minutes.
--
Bob
On 1/31/22 11:39, Jordan Brown wrote:
On 1/31/2022 7:00 AM, Jim Witte wrote:
(I know, my question/answer ratio is low..) What would be an
efficient (!) way to do a linear extrusion of an SVG with a variable
scale factor determined by a math function?
I can think of doing multiple small steps, each with a different
scale factor (tangent to the curve), and then (maybe) hulling each
"slice pair" (hull shouldn't be needed as as each "slice pair"
should already be continuous).
But that would be god-awful expensive, especially with a complicated
SVG? Can anyone think of a better way to do it? maybe something
that would make a single slice, and then shear it for each successive
slice - or is that basically what linear_extrude with scale does do?
Here's a possible implementation. Substitute your own 2D shape
(including an SVG import) for the square().
// linear extrude the children to height h, using scales a[] for each step.
module variable_extrude(h, a) {
steps = len(a)-1;
step_h = h/steps;
for (i = [0:steps-1]) {
z = i*step_h;
s0 = a[i];
s1 = a[i+1];
translate([0,0,z]) {
linear_extrude(height=step_h, scale=s1/s0, slices=1)
scale(s0)
children();
}
}
}
a = [ for (i=[0:50]) sin(i/50*360) + 2 ];
variable_extrude(50, a) square(10, center=true);
A nightly-snapshot variant that passes in a function is left as an
exercise for the reader.
F5 render says 0.05s; F6 render says 5s.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
