Nabble has removed Mailing-list integration.
Posts created here DO NOT GET SENT TO THE MAILING LIST.
Mailing-list emails DO NOT GET POSTED TO THE FORUM.
So basically the Forum is now out of date, we are looking into migrating the history.

# Better way of creating a curved slope?

30 messages
12
Open this post in threaded view
|

## Re: Better way of creating a curved slope?

 On 2/27/2021 5:00 PM, adrianv wrote: I think you understand what I mean. I understood what you meant... I just didn't understand how you got your results using linear_extrude.  And the answer is that you didn't. The problem is you cannot create a square in OpenSCAD that has vertices along its sides because collinear points are removed. So I've discovered :-) To get a model I think is good I had to use other methods.  I created my model in BOSL2 using skin(), which will accept any point list and doesn't "simplify" away the collinear points.   Yeah, I wrote a quick-and-dirty linear_extrude replacement that consumes a point list rather than a 2D shape, and with a 40-point square it produces a result much like yours. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: Better way of creating a curved slope?

Open this post in threaded view
|

## Re: Better way of creating a curved slope?

 Interesting, in openscad, if I set \$fn=10000; it looks quite nice, (much larger value  than that and my w10 pc tends towards freezing). Low values e.g.  \$fn=4, could be useful too! However, using \$fa or \$fs can not get to a very fine resolution before warning messages are produced. The \$fn value for this object seems to be about 4 times the number of 'slices'.  \$fn =1000, I would guess will most likely give the same result  as for secant_tolerance =0.001 in AngelCAD, and would give more or less 250 'slices', Is it the default low \$fn value that gives the 'terrible result'? On 28/02/2021 10:11, Carsten Arnholm wrote: On 27.02.2021 19:38, adrianv wrote: Is that in a dev version?  Because when I try intersection(){    linear_extrude(15, twist=90, convexity=8)      square(10,center=true);    translate([50/2,0,0])cube(50,center=true); } I get this pretty terrible result: I get the same in OpenSCAD 2021.02.27.nightly (git c31925e) under Kubuntu 18.04 However, if you run the exact same .scad code with no modifications in AngelCAD, you get the result shown in the attached twist2a.png file. And, if you run the exact same code again with no modifications, but specify an external argument "secant_tolerance=0.001" to AngelCAD, you get the result shown in the attached twist2b.png file. Carsten Arnholm ```_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org ``` _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: Better way of creating a curved slope?

 On 28.02.2021 12:49, Ray West wrote: > Is it the default low \$fn value that gives the 'terrible result'? Yes, for the most part. The required discretization is a function of the twist angle and any built-in curvature in the model. In this case it is the wist angle alone. Carsten Arnholm _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: Better way of creating a curved slope?

Open this post in threaded view
|

## Re: Better way of creating a curved slope?

Open this post in threaded view
|

## Re: Better way of creating a curved slope?

 cacb wrote You can do much more advanced and interesting FEM meshing with ftetWild https://github.com/wildmeshing/fTetWildWith that software you can provide an STL with skinny triangles and it will automagically do the surface remeshing and produce nice 3d tetrahedron finite element meshes in .msh format, it can be visualized using http://gmsh.info/ Well, in the case being discussed here, remeshing skinny triags will not be of any help. The problem is indeed the implementation of linear_extrude, where nonplanar quads get triangulated. in CSG a linear_extrude(10, twist=40) translates with default values to ```linear_extrude(height = 10, center = false, convexity = 1, twist = 40, scale = [1, 1], \$fn = 0, \$fa = 12, \$fs = 2) ```However, when you specify the slices parameter the CSG will look like this: ```linear_extrude(height = 10, center = false, convexity = 1, twist = 40, slices = 30, scale = [1, 1]) ```Specifying the slices parameter will effect the twist operation only, while \$fn, \$fa, \$fs will also set a default value for the children of linear_extrude(); As slices has only a vertical (z-axis) subdivision effect, in many cases it could be advantageous to also introduce a (horizontal) subdivision scheme as Adrian showed in his example. For this, I think it might be worth to make a feature request for a new "subdivide" parameter defaulting to 0 for backward compatibility and allowing us to request a horizontal slicing for the twisted linear extrusion by writing something like: ```linear_extrude(height = 10, convexity = 3, slices = 30, subdivision = 3) children() ``` Sent from the OpenSCAD mailing list archive at Nabble.com._______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: Better way of creating a curved slope?

 On Sun, Feb 28, 2021 at 5:41 PM Parkinbot <[hidden email]> wrote:...For this, I think it might be worth to make a feature request for a new "subdivide" parameter defaulting to 0 for backward compatibility and allowing us to request a horizontal slicing for the twisted linear extrusion by writing something like: `linear_extrude(height = 10, convexity = 3, slices = 30, subdivision = 3) children()`There is already such an open feature request here: https://github.com/openscad/openscad/issues/3411The main thing needed is to come to some consensus on the API for such a feature.  The discussion went a bit off the rails towards the end, but any fresh thoughts would be welcome.It sounds like you've suggest to subdivide all edges by a constant factor, but that seems like a bad idea since you could be extruding this:    square([100,1]);or even worse something like    hull() { circle(1, fn=\$30); translate([100,0]) circle(1, \$fn=30) }You wouldn't want the 1 unit sides of the square to be divided up into 100 pieces or however many times as the long side, and the circle arc segments would be subdivided even tinier.Personally I think the best way to do it is to specify a "max edge length", and split any long edges into however many parts are needed to satisfy that length.The max edge length could be a new parameter, or the special variable \$fs could simply be re-used , but I'm not sure if that's the best idea either.  Using \$fs would require a way to disable it with a bool flag if that were done (defaulted to disabled for backwards compatibility).Another idea I just started to consider would be to make this subdivision / segmentation of 2D geometry into its own operation, independent of linear_extrude.  Since it might be useful in some other scenarios.On a related note, today I finally tracked down the source of the collinear edge merging and disabled that:https://github.com/openscad/openscad/pull/3698So that should at least make user workarounds a bit simpler. (nophead's solution of perturbing vertices by small amounts would no longer be needed)Hans  _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: Better way of creating a curved slope?

 Although disabling the collinear edge merging allows workarounds they may not be so simple as happens in the case of your hulling of two circles. The  "max edge length" parameter seems to be the easiest for the users.Em seg., 1 de mar. de 2021 às 01:58, Hans L <[hidden email]> escreveu:On Sun, Feb 28, 2021 at 5:41 PM Parkinbot <[hidden email]> wrote:...For this, I think it might be worth to make a feature request for a new "subdivide" parameter defaulting to 0 for backward compatibility and allowing us to request a horizontal slicing for the twisted linear extrusion by writing something like: `linear_extrude(height = 10, convexity = 3, slices = 30, subdivision = 3) children()`There is already such an open feature request here: https://github.com/openscad/openscad/issues/3411The main thing needed is to come to some consensus on the API for such a feature.  The discussion went a bit off the rails towards the end, but any fresh thoughts would be welcome.It sounds like you've suggest to subdivide all edges by a constant factor, but that seems like a bad idea since you could be extruding this:    square([100,1]);or even worse something like    hull() { circle(1, fn=\$30); translate([100,0]) circle(1, \$fn=30) }You wouldn't want the 1 unit sides of the square to be divided up into 100 pieces or however many times as the long side, and the circle arc segments would be subdivided even tinier.Personally I think the best way to do it is to specify a "max edge length", and split any long edges into however many parts are needed to satisfy that length.The max edge length could be a new parameter, or the special variable \$fs could simply be re-used , but I'm not sure if that's the best idea either.  Using \$fs would require a way to disable it with a bool flag if that were done (defaulted to disabled for backwards compatibility).Another idea I just started to consider would be to make this subdivision / segmentation of 2D geometry into its own operation, independent of linear_extrude.  Since it might be useful in some other scenarios.On a related note, today I finally tracked down the source of the collinear edge merging and disabled that:https://github.com/openscad/openscad/pull/3698So that should at least make user workarounds a bit simpler. (nophead's solution of perturbing vertices by small amounts would no longer be needed)Hans  _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org