I would like to come back to our discussion of more than 1 month ago. Em sáb, 6 de abr de 2019 às 17:01, Ronaldo Persiano <[hidden email]> escreveu:
It was clear, I suppose, that there is no C1 triangular Bezier patch (tripatch) that meets the conditions we were looking for to round the corner of a cube. And we were looking for a C2 patch joint! Meanwhile, I have studied the conditions for a G2 tripatch joint, that is, conditions that assures a geometric continuity of first and second derivatives instead of parametric continuity. In a G1 joint between two patches they must have the same tangent plane at each joint point. A similar weaker condition is demanded for G2 patch joints. Geometric conditions are in general weaker than the parametric ones. I will not present here the development and theoretical support of the G2 tripatch I have found. This development is a bit technical so I will just show one solution for a tripatch with a G2 joint to round corners where exactly 3 edges meet. It is intended to be considered for modeling evaluation. Fixing the 2 possible form factors, the control points of the standard 5th degree tripatch is:
By standard, I mean it should be affine transformed to meet the corner position, edge directions and rounding extension. So, to round a given corner with coordinates P0 and edge directions d1, d2 and d3 with an extension r, the CPs of the rounded corner are computed by:
This tripatch is G2 and it meets the condition of geometric continuity of first and second derivatives. Here is an image of that tripatch meeting its mirror transform for a corner at the origin and edges along the axis. In the image, the joint curve is represented in yellow. Thanks to the standard tripatch, we could round all the corners of some polyhedra other than cubes. Here is an example of its application to a tetrahedron, a dodecahedron and a slanted dodecahedron. In the computation of the standard control points, two form factors may be arbitrated by the caller, one of them being the form factor of the 4th degree curve which is the joint curve of the patches. The computation implies the solution of a linear system of 6 equations for each pair of form factors. The logic behind that computation is, as I said, a bit technical. I may disclose the code that does the computation if someone is interested in but be aware that, although it is fully commented, it is not easily understandable without the technical fundamentals. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
That is very interesting. Here is a comparison of a cube made from a hull of
triangular patches and a cube made from a hull of (degenerate) rectangular patches. <http://forum.openscad.org/file/t2477/cubes.png> It sort of looks like there's something funny going on at the boundary of the tripatch, but I suppose it must be just a rendering artifact. I am printing some test cubes to see if I can tell the difference. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Does the boundary of your tripatch have an order 4 bezier representation? It
sounds like you constructed the match to match up with such a curve? What are the order 4 control points for the patch you posted? My FDM printed models are inconclusive because the shape of the roundovers is not similar enough. The case I did with spheres does seem worse, despite the limited resolution of my layer thickness---I printed with 0.15mm layers. I might try another test with 0.05 layers after a better effort to match the shape of the roundovers. But ultimately there's a problem that the limited z resolution makes this less important. I suppose someone with SLS or some other higher resolution output device would notice the difference more clearly. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I was studying my 3d printed models some more and noticed that the highlights
on the roundover from the right direction appear to have a corner, which raises questions about the curvature continuity. Another observation is that the behavior of those highlights is visually odd, as compared to the highlights from the degenerate rectangular patch, where the highlights don't do anything strange. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by adrianv
Thank you for your interest in the solution I proposed. Does the boundary of your tripatch have an order 4 bezier representation? It Yes, the border of the standard 5th degree tripatch is indeed 4th degree Bezier curve like the ones we considered for 2D cases with curvature continuity. Its degree was elevated to 5 in order to have more freedom in the internal control points of the patch. The control points of the 3 border curves of the standard 5th degree tripatch are:
They correspond to 4th degree curves with a form factor of r0=0.4. Another possible form factor appeared in the development of the tripatch. Its effect is restricted to the interior of the patch and do not affect its border. That form factor were arbitrated to be 1 in the standard 5th degree tripatch I proposed before. My FDM printed models are inconclusive because the shape of the roundovers It seems to me that to compare the standard tripatch with the degenerated rectangular one, this last one should be generated with the same form factor 0.4. Otherwise, the corner border curves (and the edge roundover) may be very different. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by adrianv
adrianv <[hidden email]> wrote: I was studying my 3d printed models some more and noticed that the highlights What do you mean here by "right direction"? Another observation is If you give me the form factor value you are using in your degenerate rectangular roundover , I could generate a standard 5th degree tripatch that meets the same form factor. Besides the form factor itself, it would be nice to have the patch border control points to check against mine patch. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by Ronaldo
Ronaldo wrote
> It seems to me that to compare the standard tripatch with the degenerated > rectangular one, this last one should be generated with the same form > factor 0.4. Otherwise, the corner border curves (and the edge roundover) > may be very different. I agree, hence the inconclusive nature of the test. However, I am definitely bothered by the funky highlights. In the pictures the tripatch is on the left, degenerate rectangle in the middle, and circular roundover on the right. The highlights look odd, which in an of itself is a negative characteristic of the printed model. It's probably the most noticeable characteristic of the curves. It seems like the tripatch has some sort of bulge compared to the other ones. <http://forum.openscad.org/file/t2477/hilights.jpg> <http://forum.openscad.org/file/t2477/highlights2.jpg> -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by Ronaldo
Ronaldo wrote
> adrianv < > avm4@ > > wrote: > >> I was studying my 3d printed models some more and noticed that the >> highlights >> on the roundover from the right direction appear to have a corner, which >> raises questions about the curvature continuity. > > > What do you mean here by "right direction"? To use more precise language: There exists a direction from which the highlight line on the model appears to have a corner (highlight has a discontinuity in its derivative). This is visible in the photo I posted in my other message. > If you give me the form factor value you are using in your degenerate > rectangular roundover , I could generate a standard 5th degree tripatch > that meets the same form factor. Besides the form factor itself, it would > be nice to have the patch border control points to check against mine > patch. I generated my patch like this: Q = cornerPatchCP([0,0,0],1.5, 0.3); using the cornerPatchCP that you previously posted. I was comparing this patch to the patch you originally posted, so the length of d disagrees, I think. I can change the patch, but for print test a larger curve is better. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
adrianv <[hidden email]> wrote: To use more precise language: There exists a direction from which the I understand it now. In fact, the images suggest something odd in the border of the tripatch. See bellow. I generated my patch like this: The standard patch has a unitary "radius". To get a bigger roundover to print, just scale it up. The value 1.5 of the second argument in cornerPatchCP correspond to scale up the standard patch by 1.5. To match the form factor of the border curves of cornerPatchCP([0,0,0],1, 0.3) you may use the following standard patch CPs:
The best approximation I got of a sphere surface with a G2 tripatch has the following CPs:
whose border curves should match the border curves of cornerPatchCP([0,0,0],1, 0.12). The second form factor I mentioned before does not affect the patch border but controls the bulge of the patch. When we decrease its value, but keeping the border curves fixed, the patch curvature varies very fast, although continuously, near the patch border which may appear as a discontinuity. Which means that the 3rd derivative near the border is higher. Perhaps, that is the cause of the highlight behavior we observe in your images. The last patch above seems to be a reasonable compromise. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
I have bad news. The patches I have stated as G2 are just G1. I have found a bug in my checkG2 function. I am sorry. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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 <[hidden email]> escreveu: Does this mean you think a G2 patch does not exist? Or just that it requires _______________________________________________ OpenSCAD mailing list [hidden email] 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 + u*b : [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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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]. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.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. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |