TLC123 wrote

Thanks for having a look at the co-linearity problem. I've only had a quick
look at your code now before bed so I mightn't understand it properly but I
would think that if you test for co-linearity and the result is true, then
you should return nothing and move onto the next set. My thought experiment
is that if there are 5 points where points 2 , 3 and 4 are co-linear,
processing points 1,2&3 together is fine likewise so is 3,4&5. If we just
skip processing points 2,3&4 it should be fine. Returning the original three
points might cause problems, I'll have a look at it though later.

TLC123 wrote

Your suggestion to limit the arc to stay within the three points, I'm
thinking out loud now, at first I thought I wouldn't work, but now I think
it could potentially work if instead of just processing the list of points
three at a time like it is currently p[i],p[i+1],p[i+2] instead it grabs the
last point from the previous arc so  arcpoints[last point of last
arc],p[i+1],p[i+2]. it would have to do something different on the first and
last iteration of the for loop, but that's seem like a nice simple solution.

TLC123 wrote

In terms of the format [[x,y,r],[x,y,r],etc], I think you're right, I think
it's better. I posted this code as soon at it was mostly working so I
haven't actually used it for anything other than the examples, but trying to
implement it today on an actual project of mine I found it confusing as to
which radius lined up with which point on the polygon. So I think I'll make
this change, but with any of those three things, feel free to make a pull
request.

I'll have a closer look at your code soon, though probably not until
Tuesday, I'm busy tomorrow.

--
View this message in context: http://forum.openscad.org/Rounded-Polygon-tp21897p21909.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

TLC123 wrote

Probably so he could draw the original polygon easily, independently of the
script, for testing.

The main reason I started the other script was to enable CSG export to
FreeCAD and then into Fusion 360, as this couldn't be done using hull (read
the thread  here
http://forum.openscad.org/Script-to-replicate-hull-and-minkoswki-for-CSG-export-import-into-FreeCAD-td16537.html
). This meant that circles and arcs keep their definition, rather than being
broken up into a mesh. Your script does seem to create a mesh, ie arcs are
broken up into straight segments, so it doesn't maintain the geometry of
circles when you import it into FreeCAD.

Unlike the other script, the points don't have to go around in a clockwise
order with yours, which is nice.

Ian

--
View this message in context: http://forum.openscad.org/Rounded-Polygon-tp21897p21910.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

droftarts wrote

Hi Ian,

short answer is if you use fn of 1 with my code it will draw the polygon
along all the tangent points only.

This was my initial approach, but I dumped it when I realised if you wanted
to have a relatively large radius compare to the overall size of the shape
than unioning it with a circle would mean the circle would take over. ie the
radius of 10 in the example, a circle that big would be bigger than most of
the shape. I thought it could be fixed by cutting the circle down before it
got unioned but at that point it seemed drawing points of the circle would
be easier.

If you wanted go back to this like I said you can use fn of 1 or you could
modify the round3points() function so that instead of passing the tangent
points and circle center to CentreN2PointsArc() it just returns these values
instead, that way you would also have the coordinates of the circle center
for the circle unioning.

--
View this message in context: http://forum.openscad.org/Rounded-Polygon-tp21897p21913.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

2017-07-23 5:21 GMT-03:00 TLC123 torleif.ceder@gmail.com:

The issue is not restricted to that extreme cases. It is enough to have
tangent points in an edge in reversed order.

module test2(size,r) {
p = [ [0,0], [size,0],[size,size],[0,size] ];
polygon( polyRound(p,r,10));
translate([0,0,-1])%polygon(p);
}

test2(100,[80,20,30,50]);

If polyRound is recoded to identify those cases, either ​it should do
nothing or reduce some radiuses. Unhapilly, the radius reduction problem
has usually many solutions.

As Ronaldo mentioned it is not straight forward to deal with conflicting
radii. But, even a robust implemention will be quite difficult, this
function is a nice-to-have if handled with care.

Here is my implementation of it. It uses $fs to control arc graining and
seems to be semantically equivalents for the rest:

--
View this message in context: http://forum.openscad.org/Rounded-Polygon-tp21897p21928.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

TLC123 wrote

Are you sure, it isn't better to report an error, instead of doing a silent
repair?

--
View this message in context: http://forum.openscad.org/Rounded-Polygon-tp21897p21948.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Yes I always round 2D shapes with a single radius using two or three
offsets but I haven't grouped it into a module. I don't use delta though. I
just use offset(-rad) offset(2 * rad) offset(-rad). Not sure what
difference it makes.

On Tue, 12 Mar 2019 at 06:44, Troberg troberg.anders@gmail.com wrote:

Would it be possible to use this tool to get rounding as is done in some
industrial designs?

https://hackernoon.com/apples-icons-have-that-shape-for-a-very-good-reason-720d4e7c8a14

If not, could someone suggest a suitable technique to achieve this?

William

On Tue, Mar 12, 2019 at 9:40 AM adrianv avm4@cornell.edu wrote:

I don't thinks so because all the rounding discussed so far uses circular
arcs that meet straight lines tangentially. That is continuous in gradient
but has a discontinuity of curvature. Possibly Bezier splines would do the
job?

On Tue, 12 Mar 2019 at 14:27, William Adams will.adams@frycomm.com wrote:

On Tue, Mar 12, 2019 at 03:06:43PM +0000, nop head wrote:

I would REALLY like to have bezier curves in openscad. The $fn parameter
would determine how many interpolation points would be used to convert the
spline to triangles.

The problem is a bit how to integrate the splines with the rest of
openscad: all primitives are 3D OBJECTS and splines usually define a
surface (in 3D if required).

We already can create an object from arbitrary 3D points, right?
(or is this only possible for 2D objects? Ah! I should know this: I
designed pyramids from 5 vertices with my niece this weekend, Duh!).

So it would suffice if a function could return a list of points (*)
corresponding to a definition of an object defined by bezier surfaces.

On the other hand, the "define bezier primitive" could internally
build on the polyhedron function: building the list-of-vertices and
faces as it processes its own input...

I think the "create bezier object" primitve would have very similar
arguments as the polyhedron primitve: A list of vertices and a list of
faces. To define a bezier patch you need precisely 16 vertices for
each patch.

Roger.

(*) Not sure if such a function can return a complex object in the
current implementation: both the list-of-points and the
list-of-vertices that define the triangles. That's be nice.

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

On 3/12/2019 10:55 AM, Rogier Wolff wrote:

Sure.  Just return a vector, the first element of which is a vector of
points and the second element of which is a vector of vertices.

Definitely none of the rounding code I've seen does this directly.  Thanks
for bringing this to my attention.  I'm actually interested in mplementing
this myself.  Does it make sense to use tangent circles to define the
location of the curved section and then fit a bezier instead of a circular
arc into the space?  Or is there some better way to define the space where
the curve should go at a given corner?  Like perhaps a setback distance
along the edge from the corner?

nophead wrote

--
Sent from: http://forum.openscad.org/

rew wrote

Does it need to be in the base language for some reason?  Bezier curves have
been implemented several times.  Here are three examples:

https://github.com/revarbat/BOSL/wiki/beziers.scad
https://www.thingiverse.com/thing:8483/attribution_is_important
https://github.com/JustinSDK/dotSCAD

And actually that third one has a bezier_smooth function that maybe does the
smooth curvature smoothing that was requested.

--
Sent from: http://forum.openscad.org/

I don't have an artistic bone in my body, so to me circles meeting tangents
are fine. I don't have any Apple products and probably never will as they
are just a waste of money. They look nice but are very unreliable and
locked in.

If I could see a need for avoiding discontinuities in curvature I am sure I
could work something out with Bezier splines but life is too short. I use
Bezier splines to approximate minimum energy curves to model bent strips.
2D Bezier curves are easy in OpenSCAD, and 3D Bezier curves are certainly
possible with polyhedron. I don't think new primitives are needed.

On Tue, 12 Mar 2019 at 23:15, adrianv avm4@cornell.edu wrote:

On Tue, Mar 12, 2019 at 11:28:24PM +0000, nop head wrote:

At first I didn't think so, then I did, now I do....

It would be VERY nice if a recursive bezier module could be built. But
that requires returning "patches" that will build up to the sides of a
polyhedron. Writing out the recursion by hand and implementing the
stack on an array is very tedious. It's like on the first day of work
you new boss points at an actual Turing machine, and says: "that's
just as turing-complete as that windows machine over there, you can
use the turing machine."

It's theoretically possible, but WAY more convenient if there is some
language support.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Isn't it just some for loops and list comprehension? I don't think it is
much harder than sweep if you want a regular array of surface points.

On Wed, 13 Mar 2019, 11:00 Rogier Wolff <R.E.Wolff@bitwizard.nl wrote:

rew wrote

If it's "theoretically possible" then after someone does it you can use the
code and you don't really care how hard it was to write.  (How hard is it to
write into OpenSCAD as a primitive?)  OpenSCAD can do recursion, so why
would you want to maintain your own stack?  What is it that you think can't
be done?  Or maybe more to the point, what exactly would your desired module
do?  Maybe we can write it.

--
Sent from: http://forum.openscad.org/

On Wed, Mar 13, 2019 at 11:41:30AM +0000, nop head wrote:

Hmm.. Ok. Maybe it's doable... I'll give it a go later on. Maybe this
weekend. Feel free to remind me. I might forget.

(I already wrote the first test-control-points and the call of the
module, and the level zero approximation.... )

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

William Adams-2 wrote

I studied Bezier curves last night (about which I knew nothing) and figured
out how cubic bezier curves can be used to achieve continuous curvature
rounding.  One parameter needs to be specified at each corner.  I'm
wondering what the best way to specify this parameter is.  It could be
specified as the distance to the intersection point of the bezier with the
edge.  Or it could be specified as the distance from the corner tip to the
maximum projection of the curve (e.g. how much is cut off).  Or perhaps
some other way relating to rounding with circular arcs?

I also wonder if it might be desirable to round in a continuous curvature
fashion but more aggressively using a higher order Bezier.  These roundovers
with the cubic bezier are rather gentle.  Anybody know how to calculate the
curvature at the endpoints of an order 4 (or general order) bezier?

Here are two examples.  The green line shows the bezier curve fit to the
corner shown in red.  Note how far back it extends before finally
terminating on the linear portion?  It means you need a long flat edge to
have room for a fairly modest roundover.

http://forum.openscad.org/file/t2477/bez.png

--
Sent from: http://forum.openscad.org/

tp3 wrote

I also didn't look in detail, but it's not apparent that these splines have
any nice derivative properties, like even first derivative control.  Having
no control parameters isn't necessary a good thing, as indicated by the
cubic bezier, which I think doesn't produce a curved enough roundover.

I did a little more analysis and I think a good way to do continuous
curvature roundovers is to use order 4 beziers.  This ends up providing two
parameters.  I'm still not sure of the optimal way to expose these
parameters to the user.  Basically with these beziers you set p0 to one end
point, p4 to the other endpoint, p2 to the point of the corner, and the
remaining p1 and p3 are symmetrically placed on the intervals [p0,p2] and
[p2,p4].  The parameters that need to be chosen are the distance, d,  of p0
and p4 from the corner and the distance a, of p1 and p2 from the corner.
Choosing a=d gives the maximum roundover, which I think is probably what is
generally desired.  If we consider doing a chamfer by simply connecting p0
and p4 then the roundover that results from a=d will put the tip of the
roundover at 5/8 of the way from the corner point to the chamfer.  Setting
a=0 puts the roundover 1/8 of the way from the corner to the chamfer.

So I could have the user specify d (the distance along the line segment to
the start of the roundover curve) or I could have the user specify the
distance to the line between p0 and p4.  And for a I can have the user
specify a value on [0,1] to control the range from 0 to d, or I could have
the user specify something from [1/8 to 5/8]*d---specifying the actual
location of the roundover tip.

Maybe I'll post some pictures later since I think the above may not be
clear.

--
Sent from: http://forum.openscad.org/

Ronaldo wrote

I'm a little puzzled.  Maybe you are using the word degree differently than
I think?  I was thinking a degree 3 Bezier is a cubic polynomial and has 4
control points.  It can be set to zero curvature at both ends but has only
one degree of freedom, which just controls the size of the curve.  That
isn't enough.  It appears to me that degree 4, with 5 control points, is
sufficient.  Yes, you do need to put p2 on the vertex.  This doesn't seem to
cause any undesirable restriction, and it is definitely possible to satisfy
the zero curvature condition.  One parameter remains that controls the
degree of curvature, as I noted in my previous message.  Having fewer
parameters is often better than more, so I'm not sure about what the value
of more degrees of freedom is of going to the case with 6 control points
(which is a 5th degree polynomial).  I did experiment a bit with your code
and you can get some rather sharp cornered results.  It seemed like r1
usually had little effect.

--
Sent from: http://forum.openscad.org/

On Wed, Mar 13, 2019 at 12:52:07PM +0100, Rogier Wolff wrote:

wrong!

I started over. I now have a bezier curve in 2D. This is at $fn = 15,
the parameter has not yet been added to the function.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

adrianv avm4@cornell.edu wrote:

You are right regarding the degrees. I wrongly said 5 instead of 4 and 6
instead of 5. A degree n Bezier curve has n+1 control points.

However I disagree that you could meet the zero curvature constraint at
both end with degree 3 curves. To have a zero curvature at the beginning of
the arc, the first 3 control points should co-linear. The same is true for
the ending point. If we require zero curvature at both ends all four
control points should be co-linear and the arc reduces to a straight
segment.

Degree 4 is in fact the minimal degree for zero curvature at both ends for
a non-straight line Bezier arc. However degree 5 solution give us not only
more degrees of freedom but a better arc shape as will see bellow. Degree 4
solution produces an arc with a greater curvature variation and a more
pointed arc. Degree 5 shape is able to produce arcs that resemble circular
arcs.

I have revised my codes in order to generate alternatively both solutions.
The two missed functions and line() module are defined as before.

q = [ [0,0], [30,0], [30,30], [0,30] ];

color("blue")  roundedPoly(q, 20, 4, 1/3);
color("yellow") roundedPoly(q, 20, 4, 2/3);
color("red")    roundedPoly(q, 20, 4,  1);

translate([35,0,0]) {
color("blue")  roundedPoly(q, 20, 5, 1/3, 17/32);
color("yellow") roundedPoly(q, 20, 5, 2/3, 17/32);
color("red")    roundedPoly(q, 20, 5,  1, 17/32);
color("green")  translate([15,15,-1]) circle(15);
}

module roundedPoly(p, n=20, degree=4, r=1/4, r0=2/3, r1=17/32)
{
assert(len(p)>2, "polygonal has less than 3 points");
assert(r>0 && r<=1, "r out of range");
assert(r0>0 && r<=1, "r0 out of range");
assert(degree==4 || degree==5, "degree should be 4 or 5");
assert(degree==5 || (r1>0 && r1<=1), "r1 out of range");
l = len(p);
q = [for(i=[0:l-1])
let( p0 = (1-r/2)p[i] + rp[(i+l-1)%l]/2 ,
p1 = p[i],
p2 = (1-r/2)p[i] + rp[(i+1)%l]/2 )
each BZeroCurvature(p0,p1,p2,n,degree,r0,r1) ];
line(q, closed=true,w=0.2);
}

// a Bezier arc of degree 4 or 5 from p0 to p2, tangent to
// [p0,p1] at p0, tangent to [p1,p2) at p2 and
// with zero curvature at p0 and p2
// n  - # of points in the arc
// r0 - form factor in the interval [0,1]
// r1 - form factor in the interval [0,1] (for degree=5 only)
function BZeroCurvature(p0,p1,p2,n=20,degree=4,r0=2/3,r1=1/2) =
assert(r0>0 && r0<=1, "r0 out of range")
assert(degree==4 || degree==5, "degree should be 4 or 5")
assert(degree==5 || (r1>0 && r1<=1), "r1 out of range")
let( r1 = degree==4 ? 1 : r1,
p  = [ p0,
p0 + r0*(p1-p0)r1,
each degree==4 ?
[p1] :
[p0 + r0(p1-p0), p2 + r0*(p1-p2)],
p2 + r0*(p1-p2)*r1,
p2 ] )
BezierCurve(p,n);

And got the following image:

[image: roundedPoly2.PNG]

At left we have the arcs of degree 4 and at right the degree 5 alternative
for similar form factors. With r=1, which means that the straight lines
between arcs reduce to a point, drawn here with red lines, the degree 4
solution keeps the middle point of each arc much nearer to the polygon
vertex. With degree 5 on the other hand it is possible to get a good
approximation of a circular arc with r1~= 17/32, a value I got empirically.

I played around a little bit with Bezier curves in OpenSCAD before, and its
fairly trivial to write a recursive bezier curve function that can handle
arbitrary curve orders.  They are also agnostic to the dimension of points
2D/3D(or higher dimension?)

Here are the functions I have used:

// return point along curve at position "t" in range [0,1]
// use ctlPts[index] as the first control point
// Bezier curve has order == n
function BezierPoint(ctlPts, t, index, n) =
let (
l = len(ctlPts),
end = index+n
)
//assert(end < l)
(n > 0) ?
BezierPoint([
for (i = [index:end])
let (p1 = ctlPts[i], p2 = ctlPts[i+1]) p1 + t * (p2 - p1)
], t, 0, n-1) :
ctlPts[0];

function flatten(l) = [ for (a = l) for (b = a) b ];

// n sets the order of the Bezier curves that will be stitched together
// if no parameter n is given, points will be generated for a single curve
of order == len(ctlPts) - 1
function BezierPath(ctlPts, index, n) =
let (
l1 = $fn > 3 ? $fn-1 : 200,
index = index == undef ? 0 : index,
l2 = len(ctlPts),
n = (n == undef || n > l2-1) ? l2 - 1 : n
)
//assert(n > 0)
flatten([for (segment = [index:1:l2-1-n])
[for (i = [0:l1] ) BezierPoint(ctlPts, i / l1, index+segment*n, n)]
]);

On Thu, Mar 14, 2019 at 1:53 PM Ronaldo Persiano rcmpersiano@gmail.com
wrote:

Ronaldo wrote

No it doesn't.  I posted graphs a few messages back showing zero curvature
order 3 beziers, and I had directly verified that the curvature was indeed
zero by calculating the derivatives both symbolically and numerically, so I
am reasonably sure it was correct.  With p0=p3 set to the endpoints of the
arc you then set p1=p2 equal to the point of the corner.  You achieve the
co-linearity condition in a degenerate fashion, since p1 and p2 are on both
lines.

It appears that your degree 4 code can also generate a nearly circular arc:
just set r1 very small, like .01 and you get something visually
indistinguishable from a circle.  In fact, it looks very similar to your
empirically determined 17/32 value.  I wonder what are the parameters for
the order 5 bezier that reduce it to the order 4.

On the left is order 4 with r1=0.01 and on the right, order 5 with r1=17/32.

http://forum.openscad.org/file/t2477/round2.png

--
Sent from: http://forum.openscad.org/

Well I'm a bit embarrassed after playing with the Bezier code I previously
posted(hadn't messed with it in a while).  I realized it had some bugs and
some inefficiencies.
I fixed it up a bit and included a more complete example with example of
various orders along random path, and a classic circle approximation.

Posting gist this time in case I need to update it again, but I believe the
code is correct now :
https://gist.github.com/thehans/2da9f7c608f4a689456e714eaa2189e6

On Thu, Mar 14, 2019 at 5:03 PM adrianv avm4@cornell.edu wrote:

You are right. Putting both intermediate control points at the corner will
meet the conditions of zero curvature at the two ends of a degree 3 Bezier
arc. I could not imagine that solution before. And certainly this is a very
constrained alternative.

I have confirmed your statement about the approximation of circular arcs by
degree 4 curves. It seems even better than the degree 5 arc with r0=17/32.

I have applied the degree elevation formulas to deduce algebraically the
conditions r0 and r1 should satisfy in order the degree 4 and degree 5
curves be equal. From my math exercise, we should have:

degree 5 with  r0 = 3/5  and r1=0 will be equivalent to
degree 4 with r0=0

I also found that r0 may be set to 0 for degree 4 and r1 may be set to 0
for degree 5 but r0 should not be 0 for degree 5 because the arc degenerate
into a line segment. I have changed the assert conditions in the my
functions accordingly.

I agree that rounding corners with degree 4 Bezier arcs give us enough
flexibility and there is no point to use greater degree. In my functions,
the parameter r of roundedPoly() controls how much the corner is rounded
like your proposed d parameter. That parameter sets the end points
relatively to the polygon edge length instead of an absolute value. The
problem with this solution is that the arc will not be symmetrical when the
two edges meeting a corner have different length. But the alternative of a
absolute value d requires a validation to avoid that two arcs rounding the
two corners of an edge intercept.

Finally, I have checked that my code works well even with not convex
polygons as can be seen in the image.

Going back to the apple article I don't think the change in shade is
anything to do with curvature. Reflected light is related to the surface
angle and that doesn't change discontinuously. It's rate of change does but
I don't see how that would affect reflected light. It looks like the left
corner is lit from both sides and the right corner is lit from right side
only.

On Fri, 15 Mar 2019 at 03:15, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

I understand your point because I am also unable to perceive visually
curvature discontinuities. But people from visual arts have training eye to
perceive it. However, even for people like us it may be noticible on
shinning and reflecting surfaces.

The following YouTube video gives an idea of the effect of different kinds
of continuity.

https://youtu.be/ryVe0aTTfrc

It was clearer to me the effect of the various kinds of continuity with the
stripe view. Designers from automobile industry are very concerned with the
effect of shadows and light reflexions on the surface of their models.

Besides, curvature continuity is a requeriment on the design of a road
track. Any discontinuity on the track is prone to an accident because a
sudden wheel turn is needed to keep the vehicle on track when you cross the
discontinuity.

nophead wrote

You wouldn't see it on completely mat or reflected surface. But on brushed
or structured surfaces a lot of additional effects accumulate. Neverless,
DIY-people like most of us in this forum, me including, with a "function
first" attitude usually have only a poor understanding of surface erotics.
Only after having read "Zen And The Art Of Motorcycle Maintenance" I could
develop a first poor understandig about what kind of gears seem to purr
within Apple customer brains.

In Open Source based 3D printing, where 90% of the prints are done with
layers >= 0.2 mm and nozzles >= 0.4mm there is no point in trying to
optimize curvatures to C3 or more.

--
Sent from: http://forum.openscad.org/

On 15/03/2019 14:07, Ronaldo Persiano wrote:

Railways used to be designed with straight and curves, and it made them
uncomfortable and restricted speeds, and ditto "loop the loop" on roller
coasters as the sudden changes in acceleration (high jerk) caused neck
injuries.

Then along came what I still call clothoid curves, but wikipedia prefers
Euler Spirals.

https://en.wikipedia.org/wiki/Euler_spiral

They are used to link straights to circles on railways, rollercoasters,
and much more.

https://en.wikipedia.org/wiki/Track_transition_curve

Interesting stuff. I wonder if we should use Euler spirals instead of
Bezier splines to round polygons.

On Fri, 15 Mar 2019 at 19:45, Gadgetmind lists@foxhill.co.uk wrote:

On 15.03.2019 17:39, Gadgetmind wrote:

Ditto, I learned about clothoid curves 35 years ago. A railway track
with immediate transition from a straight segment with zero curvature to
1/r in a circular segment will introduce a sudden sideways acceleration.
Not good. Railway tracks and motorways therefore use clothoid transition
curves.

I agree with those who say this does not matter for 3d printing though.

Carsten Arnholm

nophead wrote

It looks to me like the Bezier solution is probably easier than trying to
fit a fragment of an Euler spiral to transition between a flat section and a
circular arc.

I compared a 4th order bezier smoothed square to a circle rounded square and
they didn't look very different.  I asked myself why not?  And after some
investigation, reached a conclusion that I think is interesting.  I also
wonder if, perhaps, I was too quick to deny the utility of 5th order bezier
for this application.  Here are three examples.  The left uses circular
arcs.  The center uses 4th order bezier with the control points chosen for
the flattest arc, which is closest to circular.  It sure looks a lot like
the left hand image.  It looks like there are little corners where the
roundover meets the side.  The right hand example is a 4th order bezier with
different parameters and it looks smooth. I would say that the difference is
apparent, and I think it would be apparent if I printed the three squares.
(Maybe I should do a test print.)

http://forum.openscad.org/file/t2477/three_squares_crop.png

So what's going on.  Do I have continuous curvature or not?  Using a
curvature parameter that goes from [0,1] where 1 places p1=p0 and p3=4, and
0 places p1=p2=p3, I calculated the endpoint curvature and it is zero on
[0,1).  At 1 I have a problem because the derivative is zero, so it's a bad
parametrization.  But then I graphed the curvature for different parameter
values:

http://forum.openscad.org/file/t2477/bezier4curvature.png

The graphs show the curvature across half the bezier curve.  Of course the
other half is a mirror image.  So what I find is that when the parameter is
close to 1 the curvature starts at 0 but there is a big spike.  So it's
continuous technically, but not really practically.  It seems like a
parameter value in the range of [.5,.8] or so should give a moderate
derivative of the curvature.  If you go smaller the curvature rises a lot
in the middle of the curve, so the curve becomes pointed.  Note also that
if you want the curve to approximate a circle it's clear that this is
accomplished best when the parameter is close to 1, because then the
curvature is constant across most of the range.

So why am I having second thoughts about wanting order 5?  Well, it seems
that with order 4, once you scale the curves to be the same size (to cut off
the same amount of the corner) there is very little variation in that middle
range.  I felt like the full range of curves coming out of the 5th order
bezier was producing some weird looking flat stuff, but maybe some more
limited parameter set would be interesting.    I may plot more graphs later.

Also from this graph I can justify why we shouldn't bother with the Euler
spiral.  The Euler spiral's nice property is that the curvature starts at
zero and increases linearly.  The 0.7 curve and 0.5 curves look like
reasonable approximations to linear.  So the results wouldn't be much
different.  And this bezier approach is very easy to work with.  I have
done an implementation that does both bezier 4th order and circular arcs,
where I allow the user to specify the size of each corner's curve
independently, and I check for collisions (i.e. you pick too large of a
curve to fit).  My intention was that it could do closed paths (polygons)
but also open paths, and paths in 3d.  And the circular arc code was more
difficult to write than the bezier code, where once you've picked the
control points, you're basically done.  Once I've done a bit more testing
I'll post it here for comment.

Is there any mechanism other than assert() to generate warning or error
messages?  Assert seems kind of clumsy, since it prints the test, and it is
always a fatal error instead of a warning.

--
Sent from: http://forum.openscad.org/

Very nice research! I am already waiting for the episode 2 :)

Is there any mechanism other than assert() to generate warning or error

Yes, you may insert an echo. I usually do something like this:

let( x = test? echo(a,b,c) 0 : 0 )

As echo() accepts HTML codes you are able to use a background color similar
to the OpenSCAD warnings.

Ronaldo wrote

Maybe not as exciting as the first plot, but I did plot the shape of the
curve as I varied the curvature parameter.  It changes so slightly that it's
hard to see if I put too many curves on the graph, so I'm showing curvature
parameters of just 0, 0.5, and 1.  What changes a lot is the location of p0
and p4.  For this case, I have set the tip of the rounded corner to be 2
units back from the corner.  The bezier curve intersects the edge of the
right angle corner 4.5 units away from the corner when the curve parameter
is 1 (red line), 7.5 units when the parameter is 0.5 (green line), and a
whopping 22.6 units if you set the parameter to zero (blue line).  So
choosing a smaller curvature parameter causes it to really vary the
curvature slowly.  This I think makes those small values not very useful,
since you are very likely to run out of room on your object for the curve.

http://forum.openscad.org/file/t2477/corner2.png

So with tagging I can get the color, but it's not going to be included in
the warning count.  I normally find that all the warning message scroll off
the message area due to the statistics report at the end.  Has anybody ever
talked about adding a warning command to the language, or extending echo to
have a warning flag that makes it count on the warning list?

--
Sent from: http://forum.openscad.org/

adrianv wrote

I realized that the curvature plots should really be done as arc-length vs
curvature instead of Bezier parameter vs curvature.  The curves with larger
parameter value have parameterizations that move very slowly near the end
points, so my previous plots underestimate the slope of the curvature there.
Also plotting based on arc-length makes it easier to understand the trade
off of really long curves to shorter ones.  I can post updated plots if
anybody actually wants to see them.

--
Sent from: http://forum.openscad.org/

I would like to see them. I would expect a parametric slow down where the
curvature is greater due to smaller norms of the parametric derivatives
there.

adrianv avm4@cornell.edu wrote:

Ronaldo wrote

Ok.  Here they are.  These are the same plots posted before, but the
curvature graph (right side) is now plotted as arc length of the bezier
curve against the curvature.  I placed the center of the bezier curve at 0
and only show half the curve, so the curves start at some negative number
equal to half their length.  Some of the curves with small h parameters are
very long indeed (up to about length 40) so I plotted everything on the same
scale and cut off some of them so it's easier to compare between graphs.  I
don't feel like the new graphs lead to any change in the conclusions.
There's not a big difference between the order 4 and order 5 curves, but the
order 5 do manage with slightly shorter lengths.  The graphs do highlight
the poor properties of the curves with h1 close to 1---worse than using a
circle in terms of smoothness due to the overshoot at the ends.  I also do
wonder how much the derivative of the curvature matters.  Will I be able to
feel the difference between cases where the curvature plot has a steeper
slope?  Or does matching curvature really suffice and seeking higher levels
of continuity is just unnecessary.  I was thinking I need to print out some
tests.  The final graph has a different scale for the curvatures to make it
easier to compare between the rather similar lines that appear on the plot.
http://forum.openscad.org/file/t2477/ncase1.png
http://forum.openscad.org/file/t2477/ncase2.png
http://forum.openscad.org/file/t2477/ncase3.png
http://forum.openscad.org/file/t2477/ncase4.png
http://forum.openscad.org/file/t2477/ncase5.png
http://forum.openscad.org/file/t2477/norder4.png
http://forum.openscad.org/file/t2477/norder5_1.png
http://forum.openscad.org/file/t2477/norder5_2.png
http://forum.openscad.org/file/t2477/ncompare.png

--
Sent from: http://forum.openscad.org/

adrianv wrote

It shouldn't be too difficult to rotate_extrude such an arc rounding a 90°
corner and to translate/rotate 8 instances to the corners of a cube and to
hull them. Have a try.

--
Sent from: http://forum.openscad.org/

Parkinbot wrote

Wouldn't rotate extruding give a shape with discontinuous curvature in the
direction of rotation?  It's the equivalent of the circular roundover, so
where it meets the linear section (the rounded edge) the curvature of the
edge will be zero and the curvature of the extruded corner will be nonzero.
It seems like some 3d bezier approach is necessary to construct the shape in
the corner.  And curvature on a surface now is a vector of two values, so
maybe matching curvature is more difficult?

If I wanted a cylinder with a rounded end the rotate extrude method should
work.

Perhaps if I did a sweep of the shape I have already constructed along a
path defined by the same shape?  Would that work?

--
Sent from: http://forum.openscad.org/

adrianv wrote

this is correct. But it is a start.

Looking at a poor man's cube with rounded edges:

r0 = 5;
r = 10;
hull() for(i=[-r, r], j=[-r, r],k=[-r, r]) translate([i,j,k]) sphere(r0,
$fn=40);

http://forum.openscad.org/file/t887/roundedcube.png

shows that you have to produce appropriate corner pieces that will have
proper transitions of the three corners. If you know where you have to go,
you can try to define a sweep path for it. For this you need to find a
proper parametrization of your path along the z-axis, that will transit from
a rect to the rounded path.

--
Sent from: http://forum.openscad.org/

adrianv wrote

I understand this and that you want to go the hard way (for which
rotate_extrude will not do).
In order to do a sweep you need to create a sequence of polygons that can be
coated. Thus you have to define this sequence so that the polygons also will
grow in the desired way (as given by roundsquare) and find the
z-coordinate sequence that will also reflect the roundsquare path and the
roundedcorners rules.
With reference to my last image: You will have to define and arrange the
extrusion polygons in the way it is shown there as layers.
As I understand your approach you currently can gradually refine a given
corner in xy-space, but you don't have the means (parameters) to produce a
sequence arranged in the same sense as these layers are: so that the middle
point will follow the roundsquare path in z direction, as well as in any
other direction.

--
Sent from: http://forum.openscad.org/

adrianv avm4@cornell.edu wrote:

Yes, that is far better and easier than the sweep idea. I am travelling
without my notebook and have no way to develop it here in detail. But I
will give you some general ideas.

A rectangular Bézier surface patch is a parametric bivariate polynomial.
Its control points (CP) are usually represented by a bidimensional matrix
of points whose columns represent the control of one of the parameter and
the rows the control of the other parameter. For instance, the surface
patch of the roundover of a cube edge like you suggested has a CP matrix
with two columns with 5 points each. It is a degree 1 by degree 4 Bézier
surface.

For the corner, we will need at least a degree 4 by degree 4 Bézier patch
which has 25 control points in a matrix 5x5.

A point in a Bézier patch with a matrix of control points P corresponding
to a pair of parameters (u, v) can be easily computed by the following
simple code:

function BPatchPoint(P, u, v) =
transpose(BezierPoint(transpose(BezierPoint(P, u)), v));

where transpose() is the matrix transpose and BezierPoint() is the function
I defined before. A polyhedral approximation of the patch can be generated
by calling this function for a matrix of parameters (ui, vi).

Given two patches joined side by side, to have curvature continuity between
them all that is needed is to satisfy the curvature continuity condition by
the rows of CPs, row by row, as they were CPs of simple independent curves.

With that in mind, we could devise a patch to roundover a cube corner with
curvature continuity.

I will be back home soon and I hope to detail this stuff in two days. I
also have some comments about your curvature study and graphs but I have to
test my ideas first.

There is an error in that code: transposition is not needed. The correct
code is even simpler:

function BPatchPoint(P, u, v) =
BezierPoint(BezierPoint(P, u), v);

As the shape of the corner roundover patch is triangular I am considering
to model it with triangular Bezier patches of degree 6.

Ronaldo wrote

No doubt that this can be easily done. I remember an older thread, where you
showed it. But how would you automatically weave in such a patch into a
sweep or polyhedron that coats a larger structure like a roundedCube? Wasn't
that one the problems?
I didn't show it in my code, but it is straightforward if you have a quad
patch (which is squashed at one end).

--
Sent from: http://forum.openscad.org/

Following that line of thought, here is a rectangular patch to provide a
curvature continuity in rounding a corner of a cube.

[image: cornerRoundingI (1).PNG]
The following image shows the mesh of control points (CPs) compared with
with the patch itself.

[image: cornerRounding-CP.PNG]

As can be seen, all CPs rest on the faces of the cube in an array where one
full row of the mesh is collapsed to a point. Some intermediate rows and
columns of the mesh are movable by changing a shape parameter, others CPs
have immutable positions. The mesh of CPs of a corner were computed by the
following code:

function cornerPatchCP(P0,d,r0=0.5) =
let( P1 = P0+d*[1,0,0],
P2 = P0+d*[0,1,0],
P3 = P0+d*[0,0,1] )
[ [for(j=[0:4]) P1+P2],                                  // i=0
let(p0=P1+(1-r0)P2,p1=(P1+P2)(1-r0),p2=P1*(1-r0)+P2) // i=1
[p0,p0+r0*(p1-p0),p1,p2+r0*(p1-p2),p2],
let(p0=P1,p1=P0,p2=P2)                                // i=2
[p0,p0+r0*(p1-p0),p1,p2+r0*(p1-p2),p2],
let(p0=P1+(1-r0)P3,p1=(1-r0)P3,p2=P2+(1-r0)P3)      // i=3
[p0,p0+r0(p1-p0),p1,p2+r0(p1-p2),p2],
let(p0=P1+P3,p1=P3,p2=P2+P3)                          // i=4
[p0,p0+r0(p1-p0),p1,p2+r0*(p1-p2),p2] ];

Although it is an awkward code, it was easier to be written following the
continuity conditions. The arguments of this function are:

P0 - the coordinates of the corner
d  - the extent of cube corner that will be rounded
r0 - a shape parameter equivalent to the shape parameter of the degree 4
curves with curvature continuity

evaluating BPatchPoint(CPs,u,v) for various values of u and v in the
interval [0,1] and draw isoparametric lines or build a mesh for a
polyhedron call.

I don't like this solution. The collapse of one CP matrix row creates an
inconvenient asymmetry that can be observed by comparing the corner
rounding surface for r0 = 0.073 with the surface of a sphere:

[image: cornerRounding-sphere.PNG]

The image suggests that we have just one symmetry axis instead of 3 as
would be desirable.

Besides, a regular sample of parameters to compute points on the surface
are very irregular with a high concentration of points in the neighborhood
of the point the row was collapsed. That is a reason to pursuit a solution
based on Bezier triangular patches.

The corner surface described above has 25 CPs and a total degree of 8. My
first glance on that indicates that a degree 4 and degree 5 Bezier
triangular patch have not enough degree of freedom to accommodate the
curvature continuity conditions. Possibly a degree 6 triangular patch, with
28 CPs, will have room to satisfy all needed conditions. That will be my
next investigation.

Parkinbot rudolf@digitaldocument.de wrote:

I have solved this problem before and reported here. My lazyUnion function
is able to not only union closed manifold but stitch patches. It is
irrelevant for that module whether the patches are manifold or not. The
only condition is that each element of the incoming list is in a polyhedron
data format. And to generate a polyhedron data format for a matrix of
points (a regular mesh) or even a triangular patch is an easy task. To have
a manifold at the end is user responsability. To get it we need that the
points on the border of a patch match the points on border of a patch it
should join to and that the whole model is watertight.

Ronaldo wrote

Good point and strategy.
That was actually the solution I showed in
http://forum.openscad.org/Rounded-Polygon-tp21897p25905.html where I did a
sweep to create a corner and hulled over 8 instances of this corner.
And it wasn't as fast as the full sweep() (30s vs. 5s), but that was (as I
started to remember), because I had used a for-loop. And a for loop always
implies a union.
I just tried a run for which I put each corner as an explicite instance into
the hull body. It looks like the compile time is indeed even faster than a
full sweep (1s only). This seems to shout for a hull_for() operator that
behaves similar like the intersection_for.

Anyway, "fast" is of course always relative, because any further Boolean
operation will take its time with these vertex monsters.

--
Sent from: http://forum.openscad.org/

Parkinbot wrote

I have not yet had the time to go over what you guys have done, but I will
get to it in a few days.

What would hull_for() do?  And is the real answer not another special
command but rather a way of passing the output of a for command as a set of
children to a calling module?  Because it seems like there are multiple
occasions where you'd like to be able to generate a set of objects with
for() and then pass them to another module that operates on them
individually.  Iff a non-unioning for() command existed then it could
replace intersection_for and would have applications in a variety of places,
I think.  Is this a simpler concept than the idea of generically being able
to return multiple children from a module?

--
Sent from: http://forum.openscad.org/

There is already a PR for a non-union option for for() as part of a built
in sweep recently. It would make intersection_for() redundant as well I
think.

On Sat, 23 Mar 2019 at 23:01, adrianv avm4@cornell.edu wrote:

adrianv wrote

This is correct. And it has been discussed several times before. I think a
practical solution would be to introduce an ungroup() operator that cancels
out a following group(){} clause in the csg file, which implicitly forces a
union.

hull() for(i=[10,20]) cube(i);

translates into the CSG tree:

hull() {
group() {
cube(size = [10, 10, 10], center = false);
cube(size = [20, 20, 20], center = false);
}
}

If you edit the CSG file to

hull() {
cube(size = [10, 10, 10], center = false);
cube(size = [20, 20, 20], center = false);
}

you obviously get the desired result. Therefore

hull() ungroup() for(i=[10,20]) cube(i);

would translate into

hull() {
ungroup{
group() {
cube(size = [10, 10, 10], center = false);
cube(size = [20, 20, 20], center = false);
}
}
}

and ungroup() would inhibit the immediately following group() clause. If no
immediate group() follows, ungroup() will be ignored or cancelled out. But,
I guess there might be also semantical implications.

@thehans, what do you think?

--
Sent from: http://forum.openscad.org/

Somehow this PR gets around the problem with hull() for( ..., union=false).
See https://github.com/openscad/openscad/pull/2796#issuecomment-466836941

On Sun, 24 Mar 2019 at 00:50, Torsten Paul Torsten.Paul@gmx.de wrote:

Parkinbot wrote

What is the difference between these two things?  Taking the hull() of an
individual cube won't do anything.

I thought the interesting case was wanting to do sequential hulls, like the
hull of every adjacent pair of objects in a list, where the list was
produced by for().

--
Sent from: http://forum.openscad.org/

adrianv wrote

The code hulls two cubes. They could be translated to create something
meaningful, but this doesn't matter for the argument. The cubes will get
unioned in the first case and then hulled, and in the second case they
only get hulled. (Better think of 8 (translated) corners to be hulled to
gain a BezierCube).
While the result is the same, it is a significant runtime difference,
whether hull() will operate over a set of objects or a unioned object.
hull() is much faster then union().

--
Sent from: http://forum.openscad.org/

Parkinbot rudolf@digitaldocument.de wrote:

Hum... There is something strange here. The following code generates a
regular cube even with F6:

hull()
for(i=[0,1]){
polyhedron([[0,0,i],[1,0,i],[1,1,i],[0,1,i]],[[0,1,2,3,4]]);
cube(0.5);
}

although the two polyhedron are defective (non-manifold). If we drop the
hull() we get a non-manifold warning with F6. So, I don't think the hull()
for(){  } construct really does any union before the hull().

Parkinbot rudolf@digitaldocument.de wrote:

We don't need a hull_for() to have a faster run. hull() disregards any edge
or facets of the objects we collect for it. It operates just on the
vertices. As we don't have a primitive point, we need to resort to
polyhedron to hull() a list of points like I do here:

$fn= 10;          // number of points in all roundover
r0 = 0.15;        // shape parameter
r  = 2;            // rounding "radius"
s  = [10,15,20];  // cube edge length

roundedCube(s,r,r0);

module roundedCube(s=10, r=1, r0=0.073) {
n=$fn?$fn:360/$fa;      // resolution
s=s[0]==undef?[s,s,s]:s; // allow for vector and number
r = abs(r);
if(r==0)
cube(s, center=true);
else {
cp  = cornerPatchCP(-s/2,r,r0);
cp0 = PatchSample(cp,n);            // corner at -s/2
Mx  =[[-1,0,0],[0, 1,0],[0,0, 1]];
My  =[[ 1,0,0],[0,-1,0],[0,0, 1]];
Mz  =[[ 1,0,0],[0, 1,0],[0,0,-1]];
cp2 = concat( cp0, [for(pi=cp0) Mxpi] );
cp4 = concat( cp2, [for(pi=cp2) Mypi] );
cp8 = concat( cp4, [for(pi=cp4) Mz*pi] );
hull() polyhedron(cp8, [[for(i=[0:len(cp8)-1]) i]]);
}
}

function BezierPoint(p, u) =
(len(p) == 2)?
u*p[1] + (1-u)p[0] :
uBezierPoint([for(i=[1:len(p)-1]) p[i] ], u)
+ (1-u)*BezierPoint([for(i=[0:len(p)-2]) p[i] ], u);

function BPatchPoint(p,u,v) =
BezierPoint(BezierPoint(p, u), v);

function PatchSample(cp,n) =
[for(i=[0:n-1], j=[0:i])
BPatchPoint(cp,i/(n-1),i==0? 0 : j/i) ];

function cornerPatchCP(P0,d,r0=0.5) =
let( dx = d*[1,0,0],
dy = d*[0,1,0],
dz = d*[0,0,1] )
[ [for(j=[0:4]) P0+dx+dy],
cCP([P0+dx+(1-r0)dy, P0+(dx+dy)(1-r0), P0+dx*(1-r0)+dy],r0),
cCP([P0+dx, P0, P0+dy], r0),
cCP([P0+dx+(1-r0)*dz, P0+(1-r0)*dz, P0+dy+(1-r0)*dz],r0),
cCP([P0+dx+dz, P0+dz, P0+dy+dz],r0) ];

function cCP(p,r0=0.5) =
[ p[0],
p[0]+r0*(p[1]-p[0]),
p[1],
p[2]+r0*(p[1]-p[2]),
p[2] ];

This is the fastest strategy I can imagine. The points sampled from the
corner patches are collected in a simple list which will be the vertices of
the fake polyhedron to be hulled. That fake polyhedron has just one face
collecting all the vertex indices. This polyhedron is defective and it is
not a manifold at all but that polyhedron is not really built, just hulled.

The second aspect of the code is that it samples the corner patch in an non
uniform distribution in the parameter space. The sample rate is poor near
the collapsed row of the rectangular patch and increases linearly up to the
opposed patch edge. As the patch is really triangular, the sampling is
geometrically more uniform.

[image: cornerSampling.PNG]

I haven't tried your code yet (although I have borrowed some lines of code
from it :) ) but I believe this last code is faster. It renders the cube in
1s with $fn=50 and in 12s with $fn=100.

Anyway, "fast" is of course always relative, because any further Boolean

It is not a monster. The number of vertices of the rounded cube is about
the same of one sphere with the same $fn. So, I would not expect anything
worst than the boolean operation with a sphere. In fact, it required just
9s to difference a cylinder crossing a rounded edge with $fn=32.

Ronaldo wrote

I think warnings are only tested and emitted on the final object.

--
Sent from: http://forum.openscad.org/

Ronaldo wrote

If you create a convex body it is indeed avoidable - even I would say, it is
a work-around if you have to recur to a lazy-union to avoid the "for union
problem".

The following code creates a random convex body and looks a bit dirty. I am
somehow very reluctant to build a serious library module on this technique:

points = [for(i=[0:30]) rands(-10, 10, 3)];
faces =  [[for(i=[0:len(points)-1]) i]];
hull() polyhedron(points, faces);  // tricky convex body

However, there are also non-convex shapes. For them you need to do a proper
sweep, so this strategy is quite limited. In general I prefer to create such
a patch in a way so that it can also be swept.

--
Sent from: http://forum.openscad.org/

adrianv wrote

It wouldn't solve the problem, because in general we have the case in which
a for-loop will create objects (even fancy polyhedra are objects) that get
hulled, and Oskar Linde's hull() function depends like a lazy union on a
point representation, which OpenSCAD is successfully hiding from user space.

But for fun, I did a quick runtime test and compared Oskar Linde's hull()
function with the fancy hull()polyhedron() approach. It turned out that
Oskar's function is indeed pretty much faster, when it comes to a higher
number of points. Good to know!

points = [for(i=[0:3000]) rands(-10, 10, 3)];

// polyhedron (points, hull(points));  // Oskar's approach: 6s

faces =  [[for(i=[0:len(points)-1]) i]];
hull() polyhedron(points, faces);  // tricky convex body 74s:

--
Sent from: http://forum.openscad.org/

I have never tried Oskar Linde's hull(). I will give it a go.

However, the bogus polyhedron technique seems to be faster and simpler. For
the advocates of more orthodox solutions, it is possible to apply hull to a
set of spherical regular polyhedron built by lazyUnion() the 8 corner
patches glued together. As hull() will consider just the vertices and
disregard the edges and faces, that seems to be a waste of running time and
coding effort.

I have not looked at the sweep technique in detail yet. My concern would
certainly be on the curvature continuity.

It is a great news (and surprise) that Oskar Linde's hull is so fast. I
will study it.

A domingo, 24/03/2019, 11:44, adrianv avm4@cornell.edu escreveu:

Parkinbot rudolf@digitaldocument.de wrote:

I have checked this comparison and concluded that the delay of the second
alternative is due to the big face in the polyhedron call. I guess that the
system does a triangulation of that bogus face. Instead of one big face I
have defined a big list of triangular faces covering all vertices and the
results were very different:

points = [for(i=[0:120000-1]) rands(-10, 10, 3)];
faces =  [for(i=[0:3:len(points)-1]) [i,i+1,i+2]];
hull() // hull() spent 0s
polyhedron(points, faces);  // tricky polyhedron spent 3s

On the other hand, Oskar Linde's hull() crashed with 6000 or more points.
If that function were used in a roundedCube code, it would crash with
$fn>=38.

Ronaldo Persiano rcmpersiano@gmail.com wrote:

There is no need to resort to bogus polyhedra to follow the strategy based
on hull(). Instead, we just build a valid polyhedron for each corner and
hull() them all. Surprisingly, the preview and render times are nearly the
same as the bogus polyhedron previous code although the code is a bit more
complex.

$fn = 40;          // number of points in all roundover
// 6560 vertices for $fn = 40
r0  = 0.073;        // shape parameter (this value approximates a circular
arc)
r  = 1.5;          // rounding "radius"
s  = [15,15,20];  // cube edge length

difference(){
roundedCube(s,r,r0);
rotate(90,[1,1,0])cylinder(r=2,h=40); // to check F6 validity
}

// round the edges and vertices of a block with dimensions s centered at
the origin
//  s  - block dimensions; may be a number or a 3d vector
//  r  - the extension of the edge ends that are rounded;
//      equivalent to the radius of a circular rouding
//  r0 - rounding shape parameter ( 0<=r0<1 )
module roundedCube(s=10, r=1, r0=0.073) {
n = $fn ? $fn: 360/$fa;      // resolution
assert(0s==0 || 0s==[0,0,0], "improper size value s");
s = s[0]==undef ? [s,s,s]: s; // allow for vector and number
assert(s[0]>0 && s[1]>0 && s[2]>0, "improper cube dimensions s");
r = abs(r);
if(r==0)
cube(s, center=true);
else {
assert(2*r<=min(s), "radius r too large for the cube dimensions");
assert(r0>=0 && r0<1, "shape parameter r0 must satisfy 0<=ro<1" );
cp  =  cubeCornerPatchCP(-s/2,r,r0); // corner at -s/2
cp0 = PatchSample(cp,n);
pd0 = cornerPoly(cp0);              // base corner patch pdat
Mx  = [[-1,0,0],[0, 1,0],[0,0, 1]]; // mirror matrices
My  = [[ 1,0,0],[0,-1,0],[0,0, 1]];
Mz  = [[ 1,0,0],[0, 1,0],[0,0,-1]];
pd1 = [pd0];
pd2 = concat(pd1, transfPdata(Mx,pd1)); // patch mirrorings
pd4 = concat(pd2, transfPdata(My,pd2));
pd8 = concat(pd4, transfPdata(Mz,pd4));
hull()
lazyUnion(pd8);                      // union of the 8 corners
}
}

// unify the polyhedron data in list mPoly and call polyhedron
// assume the final polyhedron has no self-intersections
module lazyUnion(mPoly) {
// acc = accumSum(l) => acc[0]==0, acc[i]==acc[i-1]+l[i-1]
function accSum(l, res=[0]) =
len(res) == len(l) ?
res :
accSum(l, concat(res, [ res[len(res)-1]+l[len(res)-1] ] ));

verts = [for(p=mPoly) each p[0] ];
nvert = [for(p=mPoly) len(p[0]) ];
accv  = accSum(nvert);
faces = [for(i=[0:len(mPoly)-1], fac=mPoly[i][1] )
[for(v=fac) v+accv[i] ] ];
polyhedron(verts, faces);
}

// transform all the vertices of each polyhedron data in list pdat by
matrix M
function transfPdata(M, pdat) = [for(pdi=pdat) [ pdi[0]*M, pdi[1] ] ];

// the polyhedron of a corner in pdat format
function cornerPoly(tpatch) =
let( n = len(tpatch) ) echo(len(tpatch),[for(i=[0:n-1])  (n-1)n/2+i ])
[ [ for(i=[0:n-1], j=[0:i]) tpatch[i][j] ], // corner vertices
// corner faces
[ for(i=[1:n-1], j=[0:i-1]) let( k = i(i+1)/2 )
each [ [ k+j, k+j-i, k+j+1 ],
if(j<i-1)[ k+j-i, k+j-i+1, k+j+1] ],
// triangular patch back faces
[for(i=[0:n-1])      i*(i+1)/2 ],
[for(i=[n-1:-1:0]) i*(i+1)/2+i ],
[for(i=[0:n-1])    (n-1)*n/2+i ],
[  0, (n-1)*n/2, (n-1)*n/2+n-1 ]
]
];

// a point in a Bezier curve
//  p - patch control points
//  u - parameter value
function BezierPoint(p, u) =
(len(p) == 2)?
u*p[1] + (1-u)p[0] :
uBezierPoint([for(i=[1:len(p)-1]) p[i] ], u)
+ (1-u)*BezierPoint([for(i=[0:len(p)-2]) p[i] ], u);

// a point in a Bezier surface patch
//  p  - patch control points (matrix)
//  u,v - parameter values
function BPatchPoint(p,u,v) =
BezierPoint(BezierPoint(p, u), v);

// sample a Bezier patch with a triangular distribuition
// cp - control points of the patch
// n  - resolution
// a total of n*(n+1)/2 points are sampled
function PatchSample(cp,n) =
[for(i=[0:n-1])
[for(j=[0:i]) BPatchPoint(cp,i/(n-1),i==0? 0 : j/i) ] ];

// control points of a Bezier patch of a cube corner with curvature
continuity
//  P0 - cube corner vertex
//  r  - the ammount of the 3 edges at the corner to be rounded
//  r0 - shape parameter
function cubeCornerPatchCP(P0,r,r0=0.5) =
[for(p=curveCP([P0+[r,r,0],P0+[r,0,0],P0+[r,0,r]],r0))
curveCP([p, [p[1],p[1],p[2]], [p[1],p[0],p[2]] ], r0) ];

// control points of a degree 4 Bezier curve
// starting and ending with zero curvature
//  p  - corner to be rounded (list of 3 points)
//  r0 - shape parameter
function curveCP(p,r0=0.5) =
[ p[0], p[0]+r0*(p[1]-p[0]), p[1], p[2]+r0*(p[1]-p[2]), p[2] ];

That code is rather fast. It takes 14s to render a rounded block with 6560
vertices.

Parkinbot, wrote:

Yes, this technique is valid just for convex bodies. For non-convex
objects, we will have eventually to recode the computation of the patches
and it will be hard to find general solutions for corners with more than 4
incoming edges. On the other hand, I don't see how to manage the rounding
for general cases with sweeps.

adrianv avm4@cornell.edu wrote:

In that last code, I still use rectangular Bezier patches with a collapsing
row of control points so I would not expect a 3-axis symmetry. The corner
patch is the same it was used in the previous code (I have just simplified
the function that computes the patch CP).

triangle or by collapsing two points together, but details were sparse on

what happens to the control points under these transformations.

I am afraid that information is not correct.

Yes, see above.

Your sweep conception seems to lead to a curvature continuity in the two
axis but I have not analysed it in detail. I can not say that the Parkinbot
sweep code really follows you original conception because I have not
studied his code. Anyway, the results of a sweeping method would be
different in nature from what I have done. I would expect that the planar
face of the rounded block by the sweep method will not be a rectangle (as
in my model) but a rounded rectangle.

I would say that this last code could be easily extended to round any
convex polyhedron where just three edges meet at each vertices (like for
instance a dodecahedron). It is possible to remodel the corner patch in
order to round corners where 4 edges meet but I don't know how extend that
to more general cases where more than 4 edges meet at some corner. I don't
know how to apply the sweep method to round a dodecahedron.

Yes, see above.

Did you get that warning with my last code? That warning usually means that
there is degenerated faces (colinear points)  or a badly structured face
list or the point list has some point not referenced by any face. If some
face is non-planar, the system triangulate it in some arbitrary way. In my
last code, the corner polyhedron has 3 non-triangulated planar faces.

I haven't understood what you have done here.

Ronaldo wrote

Are you sure?  Are bezier patches or curves a different representation of
the degree n (or degree n,m) polynomial, or are there polynomials not
represented by the bezier framework?  It appears just based on counting
parameters that it should be possible to get all polynomials with a bezier
representation, which would mean the claim I quoted above is true...but
perhaps not very interesting without a control point mapping.

I haven't studied his code yet either.  I have to first understand the sweep
function, so it seemed like a bit more work.  It seems possible that the
result would be different in nature, but I don't agree that the planar face
would be rounded.  Suppose I sweep a square along a line.  The result---a
standard linear extrude---is a cuboid shape with rectangular faces.  If I
sweep a rounded-corner square along a line I will get a cuboid shape with
rounded edges, four rectangular faces, and then two ends whose faces are the
rounded corner square.  If I sweep a rounded corner square along a rounded
corner square then (assuming the roundover doesn't dominate the square), the
square's sides will have flat sections and the sweep will convert these into
rectangular faces.  I think that the resulting shape should actually be
identical to the shape produced from the bezier method except (possibly) at
the corners.

Yes, definitely it should be straight forward to adapt your approach to a
meeting of 3 edges, and the ordinary square bezier can handle corners where
4 edges meet.  I wonder if the triangular bezier can be generalized to an
n-gon bezier defined somehow on a regular n-gon?

What the sweep approach can (at least in principle) do is apply a roundover
to an (arbitrary?) shape that is generated by linear extrusion.  Basically
instead of doing linear extrusion you sweep along the shape's boundary a
rounded rectangle of the appropriate dimensions to create the desired shape.

No, not with the latest version of your code.  With tests of the application
of hull() to bogus polyhedra.

Your earlier version of the bezier code used the bogus polyhedron method
with one large face.  I substituted small bogus triangles and it got
slightly slower when there were 40000 points in the patch.  But when there
were 160000 bogus triangles were much faster than one huge bogus face.

--
Sent from: http://forum.openscad.org/

adrianv avm4@cornell.edu wrote:

Yes, I am quite sure. A rectangular Bezier patch with degrees n and m is in
a (large but incomplete) subset of all two variables polynomials of degree
(n+m). A triangular Bezier patch of degree n is really a  two variable
polynomial of degree n and it has (n+1)(n+2)/2 coefficients (CPs). In our
case, degree 4, triangular patches have 15 CPs while a rectangular patch of
degree 4x4 will have 25 CPs. I guess that positioning appropriately those
25 CPs we would get any degree 4 polynomial in two variable. But the
interrelations of those CPs will be something much more complex than you
have referred. At the end, just 15 degree of freedom will remain. There is
no sampling that would exempt the fulfillment of those 10 relations.

Yes, definitely it should be straight forward to adapt your approach to a

As far as I know, there is no n-gon Bézier patch for n>4.

The way I have defined that large bogus face, by taking each 3 points in
sequence as vertices of a triangle, some vertices may remain untouched by
any face when the number of vertices is not multiple of 3 and that will
generate a warning like you get.

Were you comparing the running time of the bogus polyhedron process with
the Oskar Linde's hull() of points?

adrianv avm4@cornell.edu wrote:

Nice work! I was following the same route but with degree 6 triangular
patch which is, I suppose, the minimum degree to have curvature continuity.
But I could not find a good way to compute curvature for triangular patches
to check my models. Anyway, I am afraid that the 3 CPs you consider free to
shape the surface should have precise positions to get curvature
continuity. I have drawn the triangular grid of your CPs and got the
following image with h=0.3.

As the central triangle is not coplanar with any of the corner planes I
think we would not have zero cross border second derivative at the patch
borders. Perhaps we get zero cross border curvature with h=0 but that is
too much restrictive.

My next step will be to compute the cross border curvature to check the
surface models.

Em sex, 29 de mar de 2019 às 17:44, adrianv avm4@cornell.edu escreveu:

The C1 continuity (first derivative) between two adjacent triangular
patches involves the co-planarity of some triangle pairs adjacent to the
common border (see fig. 1). It is in some sense an extension of the
condition that holds for curves. The C2 continuity (second order) requires
the coindicence of some points extending from some triangles in a second
row away from the common border (see fig. 2). The figures were taken from
Farin's paper found at
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.413.7346&rep=rep1&type=pdf.
Although this is the main reference on the subject, its nomenclature is
hard to follow. I have tried without success, to express by triangular
patches the cylindrical surface of an edge rounded with the degree 4 curve.
That would help me to try meeting the necessary C2 continuity.

So this raises the questions:  Is the code correct?  Is it possible to match

This depends on what you mean by correct. I haven't seen nothing wrong with
your functions.
I still believe we could achieve the necessary C2 conditions with
triangular patches with even degree. If the 4x4 rectangular patch I built
really matches the conditions (and I am still unsure about it), then at
least a degree 8=4+4 triangular patch will do it.

Yes, possibly with a higher degree representation.

// given p, the Bezier CP of an arc of degree len(p),
// find the control points of the same arc expressed as a curve of degree
len(p)+n

function BzDegreeElevation(p, n) =
n==0 ? p :
let(q = [ p[0],
for(i=[1:len(p)-1], u = i/len(p))
u*p[i-1] + (1-u)*p[i] ,
p[len(p)-1] ] )
BzDegreeElevation  (q, n-1);

Ronaldo wrote

My patch is failing C1 even though it appears to me that I meet the
coplanarity condition for the triangles adjacent to the edge.  What is
wrong?

I have not been successful thus far at deciphering the C2 condition from the
paper.

I did confirm that my patch edges matches the shape of the 1d curve I
previously produced with the order 4 bezier.

--
Sent from: http://forum.openscad.org/

adrianv avm4@cornell.edu wrote:

Thank you for that reference: a very useful procedure.

I am also surprised that the coplanarity condition is not enough to a C1
joint. I guess I missed something from the references and that something
else is needed. I was not successful in my attempts to model a C2 or even a
C1 corner with degree 6 tripatches. However I got a tripatch model for the
cylindrical shape of the edges.

It is clear that the coplanarity condition is not preserved when we promote
a degree elevation of your degree 4 model. When we apply the degree
elevation of 1 degree to your model, the middle triangle of the border is
no longer orthogonal to the edge curve plane.

[image: DegreeElevationTo5.PNG]

To get the degree elevation I use the following function:

// find the representation of a degree n tripatch p as a degree n+m tripatch
function triPatchDegreeElevation(p, m) =
m==0? p:
let( n = len(p),
q = [ p[0],
for(i=[1:n-1], u = 1-i/n )
[ up[i][0] + (1-u)p[i-1][0],
for(j=[1:1:i-1], v = j/i )
(1-u)vp[i-1][j-1] +  (1-u)(1-v)p[i-1][j] +
up[i][j],
up[i][i] + (1-u)p[i-1][i-1]
],
[ p[n-1][0],
for(j=[1:1:n-1], v = j/n ) vp[n-1][j-1] + (1-v)*p[n-1][j],
p[n-1][n-1]
]
] )
triPatchDegreeElevation(q, m-1);

Note that this function supposes the input tripatch p is a triangular
matrix bellow the diagonal and not above as you defined in your codes.

The cylindrical shape of a rounded edge (a sweep of the degree 4 border
curve) may be modeled by:

function cylindricalPatchCP(p0, p1, p2, d, r0) =
let(  cv = curveG2CP([p0,p1,p2],r0),
bs = BzSubdiv(cv,1/2) )
[ [bs[4]+d],
[ bs[3]+3d/4, bs[5]+3d/4 ],
[ bs[2]+d/2, 2*(bs[4]+d/2)-(bs[2]+bs[6]+d)/2 , bs[6]+d/2 ],
[ bs[1]+d/4, (cv[1]+cv[2])/2+d/4, (cv[2]+cv[3])/2+d/4, bs[7]+d/4 ],
cv
];

// our well known degree 4 curve

function curveG2CP(p,r0=0.5) =
[ p[0], p[0]+r0*(p[1]-p[0]), p[1], p[2]+r0*(p[1]-p[2]), p[2] ];

// Bezier subdivision of CP p

function BzSubdiv(p,u) =
len(p) == 2 ? [p[0], (1-u)p[0]+up[1], p[1]] :
[ p[0],
each BzSubdiv([for(i=[0:len(p)-2]) (1-u)p[i]+up[i+1]],u),
p[len(p)-1] ];

That patch makes a clear C1 joint with its mirror image along axis x. This
two patches satisfy the planarity condition at the common border even with
a degree elevation.

Taking all this in consideration, my next attempt will be to find a model
such that both itself and its 1 degree elevation satisfy the condition of
orthogonality of the border triangles and the plane of border curve.

I forgot to mention: the parameter d in cylindricalPatchCP() should be
[0,0,0] to get the cylindrical shape. Parameter d deforms the shape without
changing its border derivatives.

Wrong explanation!

In this version of cylindricalPatchCP(), p0, p1 and p2 are the three points
defining the degree 4 border of the patch. The parameter d is the tip of
the tripatch opposed to that border. A typical call would be:

cylCP  = cylindricalPatchCP([10,0,10], [10,0,0], [10,10,0], [30,0,0], r0);

Em sex, 5 de abr de 2019 às 16:36, Ronaldo Persiano rcmpersiano@gmail.com
escreveu:

I am also surprised that the coplanarity condition is not enough to a C1

I understand now what was my misunderstanding of the coplanarity condition
for C1 joints. The condition is valid for the graph of real-valued
polynomials and not for muiti-valued polynomials as the tripatches. Both
references we got are concerned with interpolation problems of real-valued
data. In this case, the first two coordinates of the graph have very
specific position depending just on the triangle domain and the polynomial
degree. Although the graph may be regarded as a surface patch, the specific
positions of the projection of the CP on the xy plane does mater.

To get a C1 condition valid for three-variate polynomials we will need to
verify the coplanarity condition for each coordinate polynomial. Taking
adrian model degree 4 patch P as an example, I graphed the three
coordinates of it:

graph(revert(P), [0,0,0], [10,0,0], [0,10,0],[0,2,0], 0.05);
mirror([0,1,0]) graph(revert(P), [0,0,0], [10,0,0], [0,10,0],[0,2,0], 0.05);
translate([7,7,0]) scale([1,1,0.01]) text("X", size=1);

translate([10,0,0]){
graph(revert(P), [0,0,0], [10,0,0], [0,10,0],[2,0,0], 0.05);
mirror([0,1,0]) graph(revert(P), [0,0,0], [10,0,0], [0,10,0],[2,0,0], 0.05);
translate([7,7,0]) scale([1,1,0.01]) text("Y", size=1);
}

translate([20,0,0]){
graph(revert(P), [0,0,0], [10,0,0], [0,10,0],[0,0,2], 0.05);
mirror([0,1,0]) graph(revert(P), [0,0,0], [10,0,0], [0,10,0],[0,0,2], 0.05);
translate([7,7,0]) scale([1,1,0.01]) text("Z", size=1);
}

module graph(p, P0, P1, P2, d=[1,0,0], w) {
n = len(p);
base = [ [P0],  for(i=[1:n-1]) [for(j=[0:i]) (1-i/n)P0 + i/n(
(1-j/i)P1 + j/iP2) ]  ];
tri_grid(base,w);
graph = [for(i=[0:n-1]) [for(j=[0:i]) [base[i][j][0], base[i][j][1],
p[i][j]*d ] ] ];
translate([0,0,1])  color("red") tri_grid(graph,w);
}

module tri_grid(p, w=0.05) {
n = len(p);
for(i=[0:n-2]) for(j=[1:n-i-1]) line([p[n-i-1][j], p[n-i-1][j-1]], w=w);
for(j=[0:n-2]) for(i=[0:n-j-2]) line([p[n-i-1][j], p[n-i-2][j]],  w=w);
for(k=[0:n-2]) for(j=[1:n-k-1]) line([p[j+k][j],  p[j+k-1][j-1]], w=w);
}

function revert(p) = [for(i=[len(p)-1:-1:0]) p[i]];

The revert is needed due to the order adrian defined his patches.

The image outcome of this code is:

[image: graphs.PNG]

where the grids in blue represent the specific arranges the down projection
of the graph CP should have and the grids in red show the graph of each
coordinate of adrian surface. Besides, I mirror the graphs in order to
check the C1 conditions. It is clear from the image that just the
coordinate z has a C1 joint with it mirror image. Both coordinates X and Y
fails to have C1 continuity at those joints.

Based on that considerations we could try to build a patch that meets the
C1 condition (and perhaps the C2 condition) at the joints. However, what we
really need is G1 and G2 continuity, that is a geometric differentiabilty
and not a parametric one. Hard stuff!

Well, I have a good news and a definitely bad one. I have found in Farin's
book ("Curves and Surfaces for CAGD") the full condition for a C1 joint
between to tripatches. Besides the co-planarity condition it is required
that any pair of CP grid triangle adjacent to the meeting border of the two
patches is an affine image of the other pairs. This affine transform should
not include any reflection, just translations, rotations and positive
scales. The following image shows the C1 joint of a degree 2 patch with its
mirror image:

[image: C1joint.PNG]

The grid in red is a mirror image of the grid in blue. The transparent
pairs of triangles satisfy the conditions of being co-planar and each one
is an affine transform of the other pair without any reflection. The joint
is C1. For patches of degree n the number of pairs to be considered will be
n.  Note that the condition excludes reflections as a possible affine
transform and the following image shows what happens when the affine
transform between pairs does not meet that requirement:

[image: NonC1joint.PNG]

In this example the adjacent pairs of triangles although co-planar does not
meet the affine condition restriction. The joint is clearly not C1.

I did try to apply this condition to model a rounded corner with a tripatch
and that is the bad news: it seems impossible to get, even the C1
condition, with a tripatch of any degree with all the border constraints of
a rounded corner we need. To understand my point, consider the following
image that schematically represents a tripatch of undefined degree intended
to round a corner:

[image: SchematicCorner.PNG]

The blue lines are the patch border and some of the grid triangles near the
patch corner are represented. Besides I added the grid triangles of the
mirrored patch near patch corner B. To meet our constraints, the grid
triangles in the patch corner should be a rectangle triangle whose
hypotenuse is towards the patch center. Then, along the border AB, we need
to have the grid triangles as illustrated and no affine transform will
bring a triangle pair near A to a triangle pair near B except with some
negative scale factor (which is a reflection). So, the conditions to have a
rounded corner with curvature continuity does not allow to meet the
condition of of a C1 joint with tripatch of any degree.

We could try to model the corner with a set of tripatches like the
Clough-Tocher scheme that uses three patches, or Power-Sabin scheme with 6
tripatches. However, to get a C2 conditions between two patches of the
scheme seems to require higher degree polynomials.

The great advantage of the use of tripatch over the rectangular patch would
be the 3 symmetries that lacks in the later. It is possible to get a 3
symmetry based on the rectangular patch solution by taking the media of
sampling the three surface patches each one collapsing a row to one corner
vertex. That would be time consuming (three evaluations of a degree 8
polynomial for each sample point).

The asymmetry of the rectangular patch does not seems great enough to
justify that onus. Besides, I have confirmed that the collapsed rectangular
patch that rounds a corner is indeed curvature continuous as we had
supposed.

The condition for a C1 joint between two tripatches I have found in Farin's
book was just that small reference:

[image: C1Farin.PNG]

It is clear that if the pair is an affine map of the domain then each pair
is an affine map the other pairs. Although the text does not say it, I have
found in my experiments that the affine map in that condition cannot
include any reflection but just translations, rotations and positive
scales. The second example of my previous message corroborates that. I have
not checked whether shears are allowed.

In my examples, the pairs of triangles meeting at the border are all
coplanars. The view angle I used to generate the images might not have
being the best. You may experiment and check my conclusions playing with
the code I have used to produce the images:

// The C1 case CP
P = [ [[0,-3,0]],
[[0,-2,1.5],[-2,-2,0]],
[[2,0,0],[0,0,1.5],[-2,0,0]]
];

// The non-C1 case CP
Q = [ [[0,-3,0]],
[[2,-2,0],[-2,-2,0]],
[[2,0,0],[0,0,2],[-2,0,0]]
];

// The C1 case
translate(){
color("red")
tri_grid(P,w);
showTriPatch(P);
%showTriPatch([[P[2][0]], [P[2][1], P[1][0]]]);
%showTriPatch([[P[2][1]], [P[2][2], P[1][1]]]);
}
// Its mirror image
mirror([0,1,0]) {
color("blue")
tri_grid(P,w);
showTriPatch(P);
%showTriPatch([[P[2][0]], [P[2][1], P[1][0]]]);
%showTriPatch([[P[2][1]], [P[2][2], P[1][1]]]);
}

// The non-C1 case
translate([0,7,0]){
color("red")
tri_grid(Q,w);
showTriPatch(Q);
scale([1,1.5,1])
mirror([0,1,0]){
showTriPatch(Q);
color("blue")
tri_grid(Q,w);
}
}

// sample a tripatch with CP cp in a triangular array

function triPatchSample(cp,n) =
[for(i=[0:n-1]) [for(j=[0:i]) BtriPatchPoint(cp, (n-1-i)/(n-1), j/(n-1))
] ];

// generates the image of the surface of a tripatch p

module showTriPatch(p,n=10) {
pdat = trimesh2polyhedron(triPatchSample(p,n));
polyhedron(pdat[0],pdat[1]);
}

// computes the point in a tripatch mapped by the parameters (u,v)

function BtriPatchPoint(p,u,v) =
len(p) == 1 ? p[0][0] :
let( n  = len(p),
pu = [for(i=[0:n-2]) p[i] ],
pv = [for(i=[1:n-1]) [for(j=[0:i-1]) p[i][j] ] ],
pw = [for(i=[1:n-1]) [for(j=[1:  i]) p[i][j] ] ] )
BtriPatchPoint(upu + vpv + (1-u-v)*pw, u, v);

// generates the mesh of a triangular array of 3D points in a polyhedron
data format [verts, faces]

function trimesh2polyhedron(p,inv=false) =
let( n = len(p),
vertices = inv ?  [ for(i=[0:n-1], j=[0:i]) p[i][i-j] ]:
[ for(pt=p, q=pt) q ] ,
tris = concat(
[for(i=[1:n-1], j=[1:i])
[ j+(i+1)(i)/2, j-1+(i-1)(i)/2, j-1+(i+1)(i)/2 ]
],
n <= 2 ? [] :
[for(i=[1:n-2], j=[1:i])
[ j+(i+1)(i+2)/2, j+(i+1)(i)/2, j-1+(i+1)(i)/2 ]
]) )
[ vertices, tris ];

module line(p,closed=false,dots=false,w=0.1)
if (dots)
for(i=[0:len(p)-1])
translate(p[i]) sphere(4*w);
else
for(i=[0:len(p)-(closed? 1:2)])
hull(){ translate(p[i])  sphere(w);
translate(p[(i+1)%len(p)]) sphere(w);
}

// draw the mesh of a triangular array of points

module tri_grid(p, w=0.05) {
n = len(p);
for(i=[0:n-2]) for(j=[1:n-i-1]) line([p[n-i-1][j], p[n-i-1][j-1]], w=w);
for(j=[0:n-2]) for(i=[0:n-j-2]) line([p[n-i-1][j], p[n-i-2][j]],  w=w);
for(k=[0:n-2]) for(j=[1:n-k-1]) line([p[j+k][j],  p[j+k-1][j-1]], w=w);
}

In your second example (with the obvious C1 failure) it appears that the

Yes, they can but mapping the triangle of a patch in the triangle of the
other patch. In the code above, I changed one of the patches in order to
make this clearer. The two patches now are not the mirror image of each
other.

In musing a bit about symmetry it has occurred to me that most applications

I am not sure this makes sense. In the method of rounding a cube by hulling
spheres, would you consider a smashed sphere to have that asymmetry?
Anyway, the asymmetry of the rectangular patch with a collapsed row is very
very mild and should not have any significant effect.

It does raise the question about potential advantages of the extrusion
approach.

I agree.

Hull only works for convex shapes, though. Minkowsky works for non-convex,
but is much slower

On Thu, 25 Apr 2019, 16:16 Anthony Walter, sysrpl@gmail.com wrote:

On 25.04.19 21:44, TLC123 wrote:

This is a very good question. Burying it in this topic after the
rant seems a bit strange though...

Also, I suspect there's no easy and single answer. Maybe that
discussion could be had, but separately. So I won't start now.

ciao,
Torsten.

On 4/25/2019 4:25 PM, Jordan Brown wrote:

And is often the case, a few searches and clicks later: 
https://en.wikipedia.org/wiki/Opening_(morphology)

See  https://github.com/openscad/openscad/issues/1678

Minkwoski difference can be done with Minkowski sum and difference but it
is very slow and uses an enormous amount of memory for values of $fn that
make things smooth.

On Fri, 26 Apr 2019 at 06:25, Jordan Brown openscad@jordan.maileater.net
wrote:

Even for convex shapes hull has limitations.  Anthony, if you think rounding
is "easy peezee" then first I suggest fixing the module so the rounded cube
is the right size rather than 2*r oversized.  Then I ask how you would make
a rounded pyramid with an arbitrary base polygon and apex that is a
designated size and not oversized.  Next, how would you use the hull method
to make a cylinder with rounded ends?  What if the cylinder's ends are not
normal to its axis?  If that's too easy then suppose I construct a parabola
and extrude it.  How would you round that?

data = [for(x=[-2:.05:2])[x,x*x]];
linear_extrude(height=4)polygon(data);

I'm not saying these things can't be done.  For making a rounded polyhedron
you need to put the spheres in the right place, which is not "easy peezee"
in my opinion when the polyhedron is not a cube.  (Oh, and don't forget that
spheres are actually polyhedra, and undersized.)  And the methods that leap
to mind for the cylinder seem little complex.  For the case of the parabolic
shape I don't see a way of using hull that is easier than just generating
the whole shape directly.

The other problem with using hull is that it assumes that it makes sense to
build up your convex object from a union of convex objects.  What if you
create your convex object through difference() operations?  Then you cannot
round the final object using hull() operations.  If everything has to be
constructed with hull() it limits your options for how you can model stuff.

As acwest notes, non-convex shapes cannot be rounded with hull.  In my
experience, nothing I design ends up being convex.  I've been pondering the
task of making a box where the inside joint between the walls and base is
rounded and the top edge is rounded.  To do this for a general box (with an
arbitrary shaped base) appears to be very difficult.

Regarding run time, hull() can be slow.  In fact, for polyhedra with large
numbers of faces it seems that minkowski() is faster than hull().  I just
did a timing test and the hull of 50 spheres with $fn=32 took 38 seconds to
preview.  I understand that technically what's slow for hull() is not the
hull operation but the unavoidable yet unnecessary union operation between
all the spheres.

It is possible to make a general minkowski rounding function with 3 calls to
minkowski.  But is has the limitation that the shape cannot have any areas
thinner than the roundover radius.  Also there is the question of speed.
Reportedly rounding the union of a cylinder and cube (that don't meet at
right angles) takes 12 hours.  And of course it enforces the same rounding
radius globally on the model, which may not be what you need.

acwest wrote

--
Sent from: http://forum.openscad.org/

Hull is only slow if it has an implicit union inside it. For example if you
place spheres with a for loop or a common translation or rotation then they
get unioned first and that is very slow with CGAL. If you place each sphere
individually, like the example above, then hull is very fast,

Spheres can be made exact by rotate extruding a semi circle with $fn a
multiple of 4. I redefine sphere myself to be that.

//
// Replicate OpenSCAD logic to calculate number of sides from radius
//
function r2sides(r) = $fn ? $fn : ceil(max(min(360/ $fa, r * 2 * PI / $fs),
5));
//
// Round up number of sides to multiple of 4 to ensure points on all axes
//
function r2sides4n(r) = floor((r2sides(r) + 3) / 4) * 4;
//
// Circle with multiple of 4 vertices
//
module Circle(r, d = undef) {
R = is_undef(d) ? r : d / 2;
circle(R, $fn = r2sides4n(R));
}
//
// Semi circle
//
module semi_circle(r)
intersection() {
Circle(r);

    sq = r + 1;
    translate([-sq, 0])
        square([2 * sq, sq]);
}

//
// Sphere that has vertices on all three axes. Has the advantage of giving
correct dimensions when hulled
//
module sphere(r = 1, d = undef) {
R = is_undef(d) ? r : d / 2;
rotate_extrude($fn = r2sides4n(R))
rotate(-90)
semi_circle(R);
}

[image: spheres.png]

I manage to make everything I need with these techniques but a version of
3D Minkowski that would run before the heat death of the universe and
consume less than an infinite amount of memory would be nice.

On Fri, 26 Apr 2019 at 12:16, adrianv avm4@cornell.edu wrote:

nophead wrote

I had forgotten about that.  It's not a very attractive coding method if you
have a lot of stuff to hull, though.  Also note that I had an error in my
code.  It actually takes 3.5 minutes to compute the hull of the 50 spheres.

That's a nice idea.

Note, however, that it only makes hulls exact for faces parallel to the
coordinate planes.  In my example problem of the pyramid it's going to be
very difficult to figure out the effective radius of the "sphere" in the
direction of each face so that you can position them exactly right to get a
hull that actually has the exact dimensions desired.

--
Sent from: http://forum.openscad.org/

Yes, for a triangular base pyramid you would want $fn a multiple of 3 I
suppose but would exact dimensions matter for such a shape when $fn is high
enough to make it smooth? I find, in generally, that only dimensions
parallel to the axes matter in my designs. They are however function over
form, with no artistic element.

On Fri, 26 Apr 2019 at 13:13, adrianv avm4@cornell.edu wrote:

nophead wrote

That's only if the pyramid is a tetrahedron with an equilateral base.  I had
suggested a generic pyramid, with arbitrary polygonal base (assume convex)
and abitrary apex position.  It's tough to even figure out where the sphere
centers should be if they are perfect spheres.

I printed models with $fn=8 and had print failures because the base of my
model wasn't coplanar due to the error in sphere dimensions.  I do note
that the base is parallel to the coordinate plane.

--
Sent from: http://forum.openscad.org/

Yes the built in sphere is missing the poles, so the base would be lifted a
bit. I would never notice because I never use a full sphere at the base
because it starts too horizontal. I use inverted rotate_extruded teardrops
when I need a rounded base, so that starts at 45 degrees. And I never use
such low values of $fn. For example this handle, which is printed flat side
down.

[image: handle.png]

Not perfectly rounded but comfortable enough to hold and easy to print. It
previews in less than a second and renders in 3 seconds. I had to avoid
implicit union inside the hull to get that speed.

On Fri, 26 Apr 2019 at 19:49, adrianv avm4@cornell.edu wrote:

On 25.04.2019 21:44, TLC123 wrote:

Good rant. I agree the efforts in developing user-space solutions in
OpenSCAD are daunting to all but a few, partly because of the
declarative language, where the order of things don't matter as in other
languages and where you cannot reassign variables. etc.

Also, the inherent slowness of CGAL seems to drive some of the advanced
efforts in user space, but the limitations of the language makes it
quite difficult to make progress in my opinion. These efforts are
commendable, but they seem to mainly try to work around limitations of
CGAL speed instead of using its strengths. Again, in my subjective opinion.

So I think that if the core is fast and the language available to the
user is rich, it means more features can be developed in user space. A
fundamental requirement is that that the core functionality runs fast
enough for non-trivial problems.

The last couple of years I have been developing an independent tool that
addresses these issues. The tool is called AngelCAD and it has recently
been released as open source, more information & downloads at
https://arnholm.github.io/angelcad-docs/

The philosophy in AngelCAD is to use a fast boolean engine (Carve)
combined with a rich scripting language (AngelScript), so perhaps it
will enable development of user space libraries

An example of rounding with AngelCAD (runs < 0.5 sec with rounding).
https://gist.github.com/arnholm/248d9a14e92b05ab8942d5f9a6611851

Carsten Arnholm

Nice, but I have no problem with the declarative functional style of
OpenSCAD  . I prefer that type of language when describing objects rather
than procedural. The huge problem is the speed and memory requirements of
CGAL. Can it be replaced by Carve in OpenSCAD?

On Fri, 26 Apr 2019 at 20:46, Carsten Arnholm arnholm@arnholm.org wrote:

On 2019-04-26 23:59, nop head wrote:

What is the reason for this preference other than having invested time
and effort into it? Is there in your opinion something fundamental that
makes it easier to describe objects this way? I can't see what it would
be. Maybe some examples can illustrate.

The features of AngelCAD illustrates that the answer is that it probably
can. Using Carve in AngelCAD has a much smaller footprint in memory and
time spent, but I can't know for sure whether this is only because of
CGAL vs. Carve, or whether it reflects how the two libraries are being
used in the host applications (point to note: Carve is used only in
xcsg, AngelCAD is the scripting front end visible to users).

Carsten Arnholm

I find a declarative language more natural for describing static geometry.
Variables do not need to change because it is a description, not an
algorithm. It's like a make file or an HTML page, both are declarative
languages. Yes you can embed script in HTML but that is only necessary to
make it interactive or to read a database. A static page of text and
graphics is just a description of a tree of objects, like OpenSCAD.

Having variables that don't change makes code more readable and less error
prone. That is why moving everything to const in C++ is encouraged. And is
more like maths, which is appropriate for describing geometry. a = a + 1 is
nonsense in maths.

I don't struggle to code anything I need in OpenSCAD but avoiding CGAL as
much as possible is tedious and makes code less readable. If it was about
1000 times faster and used 1000 times less memory I could code directly in
3D rather than decomposing everything into unions of extruded 2D. And
rounding in 3D with minkowski would be practical.

On Sat, 27 Apr 2019 at 06:39, arnholm@arnholm.org wrote:

BTW, I don't think your pyramid has the correct dimensions, as Adrianv
eluded to, it is not trivial to place the spheres for a non rectangular or
irregular shape. However, I don't see why exact dimensions would be
important to such shapes.

On Sat, 27 Apr 2019 at 09:13, nop head nop.head@gmail.com wrote:

On 27.04.2019 10:13, nop head wrote:

These are personal preferences, which is fine. In OpenSCAD users are
describing series of operations using parameters, i.e. describing what I
consider algorithms to generate models, they don't provide explicit
descriptions of the finished product. But this is semantics and not a
big deal in my book.

In some cases you have to use convoluted recursive procedures to build
datastructures in OpenSCAD, those are algorithms as well. Nothing wrong
with recursion, you can use it in AngelCAD to, but there it isn't the
only option on the table.

That is not really what constness in C++ (or AngelCAD) is about. What
makes readable code is debatable. For example, if you do this in OpenSCAD

radius = 1000;
radius = 500;
sphere(radius);

Is it supposed to be legal, and if so what is the correct result? Is the
result consistent with the statement that variables don't change?

If you do instead

radius = 500;
radius = 1000;
sphere(radius);

you get a different result, but considering the idea that the order of
things are not supposed to matter in the OpenSCAD language, the result
seems counterintuitive to me.

In this trivial case it is easy to spot that something is odd, but if it
is part of a larger section of code it is indeed error prone. With error
prone I mean it doesn't match the user expectation, given the language
rules of supposed constness and independence of sequence.

In summary, whatever the rules and syntax of a language, there are
plenty options to write unreadable and confusing code in any language
and OpenSCAD is no exception in this regard.

This agrees with my first point earlier. Because of the slowness of CGAL
and/or how it is applied, you end up working around the core feature of
OpenSCAD.

Carsten Arnholm

On 27.04.2019 10:27, nop head wrote:

It depends on what one considers 'correct'. Depending on the definition
of 'correct' for this case, I agree that placing the spheres can be
non-trivial.

I loosely designed it using the philosophy you explained earlier: "I
find, in generally, that only dimensions parallel to the axes matter in
my designs."

So, the pyramid was made to give reasonable dimensions on the main axes.
Of course, one could write more elaborate schemes giving different
results, that's the beauty of systems such as OpenSCAD or AngelCAD where
the user has endless possibilities to customize.

Carsten Arnholm

(warning: rerant on the rant)

On Thu, Apr 25, 2019 at 3:45 PM TLC123 torleif.ceder@gmail.com wrote:

I find all these things you mention intellectually interesting, and I
find minkowski interesting and useful.

However, at the end of the day, all I want to do is round off the
sharp corners on the outside (and inside corners!) of my model so I
don't have to file them off in post processing.

Minkowski drives me crazy because it is extremely slow, AND because I
have to change all the dimensions of my model to keep it dimensionally
accurate.  I just want to file off the corner, not add an extra layer
on the outside of my model.

All the OpenSCAD tutorials show doing this with hulls (work work for
me, model is concave), or lots of complex subtractive geometry (it was
hard for me to make this the first time, and you want me to do it
again backwards?), these are just ugly options.  Makes me want to go
back to solidworks where I could just select the edge and be done.

Are we making a cad program here or a pretty mathematical abstraction
with no practical application?

When you say this object is the difference between a cube and cylinder I
see that more of a description than an algorithm. The actual algorithm to
do that in user space is very difficult. It takes CGAL seconds to do it
when the cylinder is smooth.

Defining variables twice in the same scope now gives a warning, so if those
are removed it is left with its intended use of overriding defaults with
the command line, or overriding defaults supplied by a library.

Forcing variables to be constants means you know they represent one value
like they would in a maths text and they can't be accidentally changed like
they can in procedural languages and where you potentially have to scan the
entire program to know what the value might be. It means you need to make
up new names for new values and that makes code more readable. For example
in a procedural language you could have a box_width to represent the inside
dimensions of a box and later add the wall thickness and have it represent
the outside dimensions. Somebody actually asked how to do that on this
list. In a declarative language you are forced to give the inside and
outside dimensions different names and that is good.

Yes it is my personal preference but modern languages are moving towards
constant variables because it is safer and better for concurrency and
efficiency. As part of a C compiler all your expressions are rewritten to
have a new variable each time a variable is changed before it is then
allocated to registers and memory.

The CGAL slowness it definitely due to CGAL, not how it is used in
OpenSCAD. I think it uses infinite precision rationals and as soon as we
have rotations and circles most coordinates are irrational. It also doesn't
short circuit facets that are unchanged in a union or difference.

Adrianv likes to define shapes where the vertices before rounding are
specified, even though they don't exist in the final model. So the spheres
of the pyramid need to be placed tangential to all three faces of the
corner, so that the faces of the pyramid are in the same position they
would be if the corners where not rounded. This is what you would get with
Minkowski rounding of a pointed pyramid without any calculation if it ran
fast enough to erode inwards and then offset outwards, but that needs two
Minkowskis and a difference, or three Minkowskis and two differences for
concave corners and is impractically slow with any real world object. So
instead people have to subtract dimensions or place spheres and use hull,
and this is where it gets complicated. All because CGAL is very slow, not
because OpenSCAD can't easily round 3D shapes mathematically.

On Sat, 27 Apr 2019 at 12:36, Carsten Arnholm arnholm@arnholm.org wrote:

On Sat, Apr 27, 2019 at 09:13:22AM +0100, nop head wrote:

It's a bit of a notation issue.

That "a = a + 1" looks a bit like an (maths) equation, but it is not.

In languages like bash and pascal you can see the difference:

the left "a" is a reference to the memory location we call A. The
right one is a reference to the value in that location. In shell programs
the latter is "$a" and the first is "a".

In pascal the assignment is written als := instead of =, to make the
distinction from the = in maths.

But in fact even when you don't write it down that way, these
distinctions happen in (almost) all languages even when not explicitly
evident from the notation.

For example: If in C you write "a+1 = a" which is mathematically the
same as a=a+1, you get the complaint: "not an lvalue" about the
assginment target that is now "a+1".

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

I don't think we will ever agree. I see that as a description of geometry,
rather than a procedure. Openscad is free to render the scene in any order
it chooses. Wikipedia says "In computer science
https://en.wikipedia.org/wiki/Computer_science, declarative programming is
a programming paradigm https://en.wikipedia.org/wiki/Programming_paradigm—a
style of building the structure and elements of computer programs—that
expresses the logic of a computation
https://en.wikipedia.org/wiki/Computation without describing its control
flow https://en.wikipedia.org/wiki/Control_flow."

I have been a professional programmer for about 30 years and mostly wrote
procedural code. I also designed my own declarative language for describing
things like build systems, OS configurations, or state charts and rendering
make files or C++, etc. That also had variables that only have one value,
although they could have defaults that were overridden, so a bit like
OpenSCAD in that respect.  It also built a tree of objects like OpenSCAD
does and then rendered them. The difference being it produced text rather
than graphics and didn't use C syntax. So OpenSCAD works the way I think.

But if you are trying to write a function to compute something (perhaps the

I don't see that at all. I have very few functions that need mutable
variables and I don't find recursion cryptic. It is more like a
mathematical description and a loop is more like a procedure.

You have to write chained ternary operators where every possibility is

The ternary statement can be formatted almost the same as if else. It is
only convention that if else is on multiple lines and ? : is on one line.

You have to generate a bunch of extra variables, which might waste memory

The memory used by the script is negligible compared to CGAL. I haven't got
anything with cryptic names like atemp1-3. If I break up expressions I give
them meaningful names but since expressions can occupy multiple lines I
don't split them up unless there are  sub-expressions I can factor out to
avoid repetition or give a meaningful name to to make the code clearer.

I have been experimenting with Minkowski rounding of this simple shape.

[image: image.png]

To preserve the original dimensions I use my version of sphere with poles
and equator and I inflate, erode by twice as much and inflate again to
round both the concave and convex corners. This took 45 minutes with $fn =
24. Curiously it stopped LibraOffice starting until it finished rendering.
I think time increases exponentially with $fn.

4 6
8 39
12 120
16 500
20 814
24 2745

[image: image.png]

Minkowski of a convex shape should be as fast as hull because all it needs
to do is take the hull of the the vertices of one shape offset by each of
the vertices of the other shape. For a concave shape it needs to decompose
it into convex shapes, Minkowski each in turn and union the resulting
hulls. The trouble is even union with lots of vertices is very slow with
CGAL. And when you erode inwards the shape is always going to be concave.

On Sat, 27 Apr 2019 at 14:44, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

It isn't the notation it the fact that in maths you don't let x mean one
thing and then on the next line make it mean some else. x means the same
thing throughout the text. You can have y = x + 1, but not x = x + 1. You
can have sigma with subscripts that make n range from 1 to something but
that is like a for loop, which OpenScad has. There are lots of programming
languages where you you can't mutate variables. It seems that most people
on this list just don't get it.

On Sat, 27 Apr 2019 at 22:10, lar3ry@sasktel.net wrote:

nophead wrote

That seems to describe OpenSCAD.  But what does that have to do with whether
OpenSCAD files are algorithms?  The word algorithm is pretty broad, and it
seems pretty clear that declarative programming is still giving algorithms.

Writing code into the required form to get tail-recursion in my experience
tends to increase code complexity and make the code more cryptic.  I'm not
saying recursion is inherently cryptic, but I think a loop is generally
easier to understand.  What if I have an algorithm that requires more than
one pass over the data to produce its output?  That may not have an obvious
solution through simple recursion.

The problem is not the ternary operator itself---that's just notation---but
the fact that you have to assign the variable with a single chain of
ternary operators.  I ran into a complication recently where I was trying to
determine the parameters to construct and object from user inputs.  I needed
to compute parameters h and r from the user inputs, but some user inputs
make it natural to compute r first and compute h from r and others have the
reverse characteristic.  In a language where I can have multiple assignments
and if statements I could have divided up the cases and computed each one in
the most natural way.  Instead I had to derive more complex formulas for
certain cases so that I could compute one of the variables first from any
user input.

This is the sort of situation I'm talking about.

I've been thinking about a routine to make a box with rounded edges and
interior corners and the major challenge is that when I shrink the boundary,
the number of vertices may change, which makes it hard to assign polyhedron
faces.  I think this would be much easier to track and handle if variables
could change.

So in the case where if a is set then r=f(a), h=g(r,a) and if b is set then
h=F(b), r=G(h,b), how would you write this?  I mean, I suppose you can do
this

r_or_h = !is_undef(a) ? f(a) : F(b),
r = !is_undef(a) ? r_or_h : G(r_or_h,b),
h = !is_undef(a) ? F(r_or_h,a) : r_or_h;

Is there some alternative, because I think that's effective at obscuring a
simple underlying relationship.

--
Sent from: http://forum.openscad.org/

On 27 Apr 2019 at 22:21, nop head wrote:

Again reinforcing my happiness in using a program instead of math.

And yet they are still called variables. Fascinating.

--
Magic trumps science for most people,
and wishful thinking drives a lot of decision-making.
- Joe Haldeman