Rounded Polygon
It means there is no degree 5 G2 tripatch that meet the constraints. I am
still working on higher degrees.
Em qua, 29 de mai de 2019 às 22:08, adrianv avm4@cornell.edu escreveu:
Does this mean you think a G2 patch does not exist? Or just that it
requires
different constraints?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I returned to the question of making continuous curvature rounded corners.
It seemed to me that the method Rinaldo showed using using a degenerate
square bezier patch of order 4 was the method that was known to be correct.
I am wondering about what exactly the general requirements are for making
this continuous curvature. It seemed plausible that the edges of the patch
need to be orthogonal to the three edges and then it needs to meet the
requirement of having the form [p0, p0+k*(p1-p0),p1,p2+k*(p1-p2)] for every
column and row across the patch.
I implemented this using the code below where k1 and k2 are the curvature
parameter that can be different in the two directions.
function fillrow(row,k) =
[
row[0],
lerp(row[1],row[0],k),
row[1],
lerp(row[1],row[2],k),
row[2]
];
function lerp(a,b,u) =
is_num(u)? (1-u)a + ub :
[for (v = u) lerp(a,b,v)];
function bpts(plist,k1,k2) =
let( k2 = is_undef(k2) ? k1: k2 )
fillrow([for(row=plist) fillrow(row,k1)], k2);
where bpts takes as input a 3x3 list of points giving the corner point, the
corners of the patch, and the centers of the patch along each edge.
Using this method I have created some examples that seem valid such as this
pentagonal prism:
http://forum.openscad.org/file/t2477/pentagon1.png
and this L-shaped prism:
http://forum.openscad.org/file/t2477/Lprism.png
Now if I change the width of curvature of the top layer then I get this
pentagonal prism that I think seems also OK:
http://forum.openscad.org/file/t2477/pentagon1a.png
And here I can change the curvature parameter of the top compared to the
sides to get something like this one:
http://forum.openscad.org/file/t2477/pentagon2.png
But if I change the curvature size for just one vertical edge, I'm not sure
the result is continuous curvature any more. The top face is not no longer
a regular pentagon:
http://forum.openscad.org/file/t2477/pentagon3.png
Another case is if I use pentagons of different scales, making a trucated
pyramid. It looks like curvature is probably not continuous.
http://forum.openscad.org/file/t2477/pentagon4.png
If I translate the top pentagon I get a result that is clearly bad:
http://forum.openscad.org/file/t2477/pentagon5.png
And likewise if I skew the top pentagonal face in the z direction it seems
something is also wrong:
http://forum.openscad.org/file/t2477/pentagon6.png
But it seems like all of these cases should have solutions. Am I right
about that? What are the general conditions that need to be satisfied for
putting C2 corners on a general prism object?
Note: if anybody wants to see the full code I'm happy to post it, but it
depends on BOSL2.
--
Sent from: http://forum.openscad.org/
Very interesting line of research, Adrian. I had to review our previous
messages to answer some of your questions.
I would say that all your examples where the rounded edges have a
(non-circular) cylindrical shape satisfy the curvature continuity. Those
cases where the rounded edges have a conical shape are not even tangent
continuous. When the edges are cylindrical its transversal derivatives
(along the edge direction) have all the same value as happens with the
corner patch . That is not any longer true when the edges are conical.
Note that the corner patch is a degenerate quad patch so the value of one
of the parameters k will affect the shape of two patch borders but the
other will affect just one because the other border is collapsed to a
point. That is a consequence of the patch symmetry to just one plane and
not three. However, the second derivative at any point on the patch border
is zero for all values of k0 and k1 in [0,1].
I realized my main error. I was constructing my corner patches so that they
were orthogonal to the edges. But the requirement is instead that the patch
edges are parallel to the edges. It's the same when the edges form 90 deg
corners, but different in the various other cases. So things are looking
better, I think. I believe that the requirement for C2 is that the first 3
of the five bezier points are collinear with the segment being rounded. I
added to my code a check to confirm this property and hopefully therefore
identify cases where it has failed.
One case of failure is if I attempt to set a curvature size for a single
vertical edge. The problem is that this setting affects the location of the
corner vertex (on the top of the surface) and leads to an inconsistency
there. However, it appears OK to change the k parameter for a single
vertical edge:
http://forum.openscad.org/file/t2477/newpent1.png
It looks a little funny, which weakens my confidence but it meets the
collinearity condition.
The pyramid version now looks like this, and passes the collinearity tests:
http://forum.openscad.org/file/t2477/newpent2.png
When I skew the top I also pass the collinearity tests and get this result:
http://forum.openscad.org/file/t2477/newpent3.png
I also tried translating the top. The result looks OK, but it is failing my
collinearity test. I am trying to figure out what's going on (whether my
collinearity test is somehow broken, or what the reason for the failure is).
http://forum.openscad.org/file/t2477/newpent4.png
It seems to me that this technique should work for any solid created from
two n-gons with n coplanar quadrilateral faces between them. I was trying
to figure out if I start with a coplanar polygon P, then under what
circumstances will the transformation T result in T(P) meeting these
requirements.
Regarding the k parameters, I believe I have the flexibility to set the k
parameter to a different value for each vertical edge, and then I can set
one value for the top and one value for the bottom, which will affect all of
the segments of the top and bottom face.
--
Sent from: http://forum.openscad.org/
Yes, the collinearity condition you checked is what supports the zero
transversal curvature at the patch borders. The patch was designed with that
in mind. You can see it by drawing the patch control point mesh.
Patches&meshes.PNG
http://forum.openscad.org/file/t1275/Patches%26meshes.PNG
One case of failure is if I attempt to set a curvature size for a single
vertical edge. The problem is that this setting affects the location of
the
corner vertex (on the top of the surface) and leads to an inconsistency
there.
What kind of inconsistency? The three vertices of the patch should be
independent of the values of k1 and k2. In your bpts() function they depend
only on the input plist. If the plist is consistent at every polyhedron
vertex I would expect no inconsistency on the top of the surface. Here is an
example of a skewed rhombus extrusion where just one edge has a k1=0.2 and
k2= 0.8 and the others have both equal to 0.2:
SkewdRhombusExtrusion.PNG
http://forum.openscad.org/file/t1275/SkewdRhombusExtrusion.PNG
I also tried translating the top. The result looks OK, but it is failing
my
collinearity test. I am trying to figure out what's going on (whether my
collinearity test is somehow broken, or what the reason for the failure
is).
I would say that it should have some bug in your code for that case. Here
are the CP of the corner patch of the distinct upper corner of the previous
image:
CornerCP.PNG http://forum.openscad.org/file/t1275/CornerCP.PNG
It may help to note that a Bezier patch is an affine function of its control
points. That means the affine transform of a patch equals the patch of the
affine transform of its control points. Therefore, all patches with a given
pair of k1 and k2 are affine transforms of a unitary patch like that:
function ubpts(k1,k2) =
let( k2 = is_undef(k2) ? k1: k2 )
let( dx = [1,0,0], dy = [0,1,0], dz=[0,0,1] )
let( plist= [ [dx+dz, dz, dy+dz], [dx, [0,0,0], dy],[dx+dy, dx+dy, dx+dy]
] )
fillrow([for(row=plist) fillrow(row,k1)], k2);
As a consequence, you may evaluate points in the unitary patch for each pair
(k1,k2) and do an affine transform of those points to each specific corner
of the polyhedron.
Regarding the k parameters, I believe I have the flexibility to set the k
parameter to a different value for each vertical edge, and then I can set
one value for the top and one value for the bottom, which will affect all
of
the segments of the top and bottom face.
In a more general setting, you can assign a different k value for each edge
of the polyhedron (convex or not) provided that the (exactly) three incoming
edges at each vertex have at most two different k values.
It seems to me that this technique should work for any solid created from
two n-gons with n coplanar quadrilateral faces between them. I was trying
to figure out if I start with a coplanar polygon P, then under what
circumstances will the transformation T result in T(P) meeting these
requirements.
Not only. The polyhedron faces may have any number of vertices. For
instance, you could do it with a tetrahedron using equal values of k at the
top vertex and two values of k at the base vertices. As I said before, the
only conditions are: exactly 3 edges meet at a corner and no more then 2
values of k are used by the edges meeting at a vertex.
Although its flexibility, it would be hard to specify such a varying edge
roundness. We can imagine that the input to such a function is the polyset
of the polyhedron, its [verts,faces] representation, with an output in the
same format. But it is hard to check that a polyset represents a valid
polyhedron (even harder to check if it has self-intersections) because there
is a lack of topological information in that representation. To build the
rounded polyhedron you need essentially the table of the adjacent vertices
to each vertex and that table requires a procedure that grows very fast with
the number of vertices (O(n2) ?). I have implemented that and it is useful
for at most something around a hundred vertices which would be acceptable to
a (itself expensive) rounding process.
--
Sent from: http://forum.openscad.org/
As I pondered a little more what was going on I realized that the chain of
assumptions leaves the "top" part of the patch (around the degenerate
corner) completely defined, and possibly with different k values than used
elsewhere. The parameters weren't as free as I was thinking. This follows
from enforcing collinearity.
Restricting to the case of prism-like polyhedra for simplicity, consider the
following requirements: I want to specify a rounding scale and k for each
vertical edge (possibly different). Rounding will be symmetric at each such
edge. At the top and bottom I also specify a rounding scale and k.
What does this require? If at a given edge the desired edge rounding is r_e
and the top rounding is r_t then this determines the position of the bottom
corners of the patch. You need to move in the orthogonal direction away
from the edge by distance r_t, which means r_t/sin(theta) where theta is the
angle of the side face at the corner. This means the distance you move is
different in the two directions if the faces have a different angle. The
distance down from the corner is determined by the angle the edge makes with
the plane of the top face according to a similar formula. Once these
points are established you can fill in all the lower half points in the
patch using the two k values, one for the vertical direction and another for
the horizontal direction.
So what about the remaining points in the patch? Well, there is where
things get complicated. Because everything that remains is already forced.
This was not obvious to me. To find the corner point at the top you need to
take the intersection of the lines from the next and previous corners. And
the k value is not free for this top section. It must be chosen in a
similar fashion as an intersection of lines defined by points already
chosen. It will not match the two chosen k values in general. So for the
case of the translated top that was my problem. And similarly if I the
roundover size varies then the location of these point intersections shift
around and you cannot determine the position without reference to the two
adjacent points in the top face.
Now this all said, there is a completely different way of specifying the
rounding that has some merit and would probably be the only way to handle
rounding of a generic polyhedron whose vertices all have degree 3. Instead
of specifying the rounding based on edges, specify it based on faces. This
method is much cleaner mathematically. For a given face, pick a rounding
length and k value. Find the plane that is shifted inward by that distance.
Repeat for all faces of the polyhedron. The intersection of points of all
the resulting planes defines all of the patches in a manner which will
obviously be collinear. This means that a given edge will have
asymmetric rounding, with one value on one side and a (possibly) different
value on the other side.
I'm not sure I believe that the patches that result, especially from the
first procedure, are in fact an affine transformation of the master patch,
given the need to choose special k values for the top part. There is
another case I think you may have overlooked, which is the concave corner
case. The patch for this case is non-degenerate, and also has to be defined
with reference to the adjacent points.
--
Sent from: http://forum.openscad.org/
I think, Adrian, our talk is becoming too much technical and specific for
the audience of this forum. Perhaps we should continue it in private
messages allowing those who manifest to be interested in the topic to join
us. I can create a Google group if necessary.
Anyway, here are some comments about your last message. I agree with the
method of defining a rounding scale in a face basis. It is relatively
simple to deal with and it seems to meet the curvature continuity
condition. It would be comparable with the method of rounding edges with
elliptical arcs instead of circular arcs.
I understand the method in a equivalent but slight different way. Given a
rounding scale for each face, consider the vertices of the negative
offset of the face by the amount of its scale. You will have one offset
vertex near to a vertex for each face-vertex adjacency . Take the 3 offset
vertices of the adjacent faces of a vertex and use them to build a patch
for that vertex. The setting of the k's may be chosen
independently provided that it is the same value at the two extremes of an
edge. The effect of the k's would be far less dramatic than the rounding
scale. I have made some experiments with that method and it seems to
satisfy all requirements. I think this method might be used even with
non-prismatic polyhedra.
Non-convex vertices is a topic for another message.
Hey adrianv,
I'm definitely up for cleaning up the interface. Sorry I'm very late to this
reply. If you wanted to open up some issues on github we could work through
them.
Would definitely be good to get things as intuitive as possible. I
definitely could improve it myself, but also perhaps I'm too close to the
code and find it harder to step back and think about it wholistically so if
you willing to help out, that would be great.
--
Sent from: http://forum.openscad.org/
I have to admit that since I wrote my own rounding library for BOSL2
https://github.com/revarbat/BOSL2/wiki/rounding.scad
I'm less interested in trying to figure out how to improve another library.
And I have my own issues in trying to simplify the API of some pretty
complicated functions I wrote. But I'd be very interested in a general
conversation about rounding, what kinds of rounding would be useful that
don't (seem to) exist yet, or how we can do rounding better.
One function I want to write but haven't figured out how to write because I
can't define its behavior well enough is a rounded path join: a function
that takes a list of paths with rounding parameters and joints the paths
together with rounding, even when the required roundover is bigger than one
segment of the path. (I already did something like this for my
offset_stroke method, which will add roundings to the end that are larger
than one segment of the path.) The problem is I am not sure how to specify
the rounding between two paths when the rounding gets large. The basic idea
would be to have a cut size or radius and to track back along the paths to
try to find a way to achieve it, but if the path wiggles a lot, this can
fail in some strange ways.
One API issue is how to specify the size of roundovers, and when I
implemented continuous curvature rounding, which doesn't have a "radius", I
realized that radius is often not very intuitive. Especially for sharp
pointing corners, radius is hard to understand intuitively. I introduced
the "cut" distance to measure the size of a roundover: this is basically
how much of the corner is cut off by the rounding process. Another API
issue I ran into with round_corners was specifying the rounding size as an
extra point on the coordinate list: this turned out to complicate my API
and was basically never useful. I also ended up deciding that decreasing
the user specified roundings when they conflict wasn't the best interface
idea, because then the user doesn't know what actually happened, and it's
hard to tweak the result. I might, for example, want more rounding, not
realize it's impossible, and get frustrated trying to increase values and
get no change. (I suppose a warning message could help in this case.) I
decided it was better to optionally display information that would help the
user find a nonconflicting set of roundings.
OpenSCAD mailing list-2 wrote
Hey adrianv,
I'm definitely up for cleaning up the interface. Sorry I'm very late to
this
reply. If you wanted to open up some issues on github we could work
through
them.
--
Sent from: http://forum.openscad.org/
I completely understand not wanting to improve another library.
I'm finding it difficult to visualise your joining path problem sorry.
--
Sent from: http://forum.openscad.org/