Yes, doing 3d rounding is definitely slow. I found that using render() with minkowski() made it kind of tolerable because I wasn't recomputing the minkowski() every time I tweaked the model. In this model I actually used minkowski() twice: once to create the channel and another time for rounding. Certainly faster solutions would be nice. The minkowskiRound() module calls minkowski() three times and the author says it can take 12 hours. I suppose one can argue that slow is better than impossible. Regarding finding the normal, I concluded that because the channel was formed from offsets and then cut that it was not obvious how to find the point on the cosine curve that corresponded to the end of the channel. I would have to solve for the equation that describes the offset from cosine (e.g. by adding its normal vector at every point?) and then I could take the derivative of that. It seemed like it was going to be a complex calculation---but also, what's the point of using offset() if I then have to turn around and compute the equation of the curve myself? Did I err in my thinking about this? If it was just determined by the underlying cosine curve it should actually be parallel to the axis at the ends, but that's not what happens. I agree that with the exception of very large roundings---like the one I used above in this thread to solve the curved edge rectangle---the two rounded polygon codes produces the same set of shapes. But at least for how I design parts and think about design, it's enormously better to define a polygon and then cut off the corners instead of defining it with a set of tangent spheres, because the locations of the sides of the polygon are the primary parameter, and when the angles are not 90 degrees, figuring out how to place the tangent spheres requires a computation. A major attraction to me of the roundPoly function I found is that it eliminates computation and lets me instead describe the desired output. I maintain that the computer should be doing the computations, not me. I suppose I could write a wrapper that computes the necessary positions for the circles and it seems like that wouldn't take 335 more lines of code. Perhaps I'll dig deeper. -- Sent from: http://forum.openscad.org/

> Did I err in my thinking about this? No. What I said would apply to a sweep of a U where the profile would be always be oriented parallel to the tangent of the path. The way you have offset from a larger polygon I am not sure the same is true. Possible it, is but since you have sliced the channel to form the ends it isn't obvious where on the path the end you want to round is. Also since the path is curved any mask would need to be curved as well, so now I appreciate your problem. >But at least for how I design parts and think about design, it's enormously better to define a polygon and then cut off the corners instead of defining it with a set of tangent spheres And this is exactly why we don't have standard libraries. My code is perfect for what I use it for, which is belt paths, where the primary parameters are the position and pitch radius of the pulleys. On Mon, 11 Mar 2019 at 01:23, adrianv <avm4@cornell.edu> wrote: > Yes, doing 3d rounding is definitely slow. I found that using render() > with > minkowski() made it kind of tolerable because I wasn't recomputing the > minkowski() every time I tweaked the model. In this model I actually used > minkowski() twice: once to create the channel and another time for > rounding. > Certainly faster solutions would be nice. The minkowskiRound() module > calls minkowski() three times and the author says it can take 12 hours. I > suppose one can argue that slow is better than impossible. > > Regarding finding the normal, I concluded that because the channel was > formed from offsets and then cut that it was not obvious how to find the > point on the cosine curve that corresponded to the end of the channel. I > would have to solve for the equation that describes the offset from cosine > (e.g. by adding its normal vector at every point?) and then I could take > the > derivative of that. It seemed like it was going to be a complex > calculation---but also, what's the point of using offset() if I then have > to > turn around and compute the equation of the curve myself? Did I err in my > thinking about this? If it was just determined by the underlying cosine > curve it should actually be parallel to the axis at the ends, but that's > not > what happens. > > I agree that with the exception of very large roundings---like the one I > used above in this thread to solve the curved edge rectangle---the two > rounded polygon codes produces the same set of shapes. But at least for > how > I design parts and think about design, it's enormously better to define a > polygon and then cut off the corners instead of defining it with a set of > tangent spheres, because the locations of the sides of the polygon are the > primary parameter, and when the angles are not 90 degrees, figuring out how > to place the tangent spheres requires a computation. A major attraction to > me of the roundPoly function I found is that it eliminates computation and > lets me instead describe the desired output. I maintain that the > computer > should be doing the computations, not me. I suppose I could write a > wrapper that computes the necessary positions for the circles and it seems > like that wouldn't take 335 more lines of code. Perhaps I'll dig deeper. > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >