discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Rounding library

A
adrianv
Tue, Aug 18, 2020 2:02 AM

OpenSCAD mailing list-2 wrote

Adrianv, sketching is very common in cad packages. See this video from
about
10s to 40s he makes a sketch https://www.youtube.com/watch?v=CbPIs4MzvzU.
Basically a bunch of points and he adds constraints by adding dimensions,
though not all are dimensions. At one point he selects two lines and
constains them to be the same length. Other things that are common is
defining a line to be vertical or horizontal, or constrain two lines to be
parallel.

This doesn't really fit the OpenSCAD framework at all.  If you want to lines
the same length...you define them to be the same length.  I liked it when he
just selected some edges and rounded them over.

tpv, not sure. I did play with an experimental API like this
<http://forum.openscad.org/file/t1892/experimental.png>
Where "L" means take the value from the previous point, and the last line
of
the polygon is defining that's it's supposed to be 45 from the Y axis and
each letter of "ayra" means something, maybe like absolute y . .  I can't
remember. Obviously it could be cleaned up but I figure it a) doesn't
shine
a light on normal sketches and b) is cumbersome. Ultimately sketching is a
GUI tool and not sure it can be translated to code in an intuitive way.

There is the concept of turtle graphics, like move forward 10, turn left 100
deg, move forward until y=3, etc.  I implemented something like this and
find it pretty useful.

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

OpenSCAD mailing list-2 wrote > Adrianv, sketching is very common in cad packages. See this video from > about > 10s to 40s he makes a sketch https://www.youtube.com/watch?v=CbPIs4MzvzU. > Basically a bunch of points and he adds constraints by adding dimensions, > though not all are dimensions. At one point he selects two lines and > constains them to be the same length. Other things that are common is > defining a line to be vertical or horizontal, or constrain two lines to be > parallel. This doesn't really fit the OpenSCAD framework at all. If you want to lines the same length...you define them to be the same length. I liked it when he just selected some edges and rounded them over. > tpv, not sure. I did play with an experimental API like this > &lt;http://forum.openscad.org/file/t1892/experimental.png&gt; > Where "L" means take the value from the previous point, and the last line > of > the polygon is defining that's it's supposed to be 45 from the Y axis and > each letter of "ayra" means something, maybe like absolute y . . I can't > remember. Obviously it could be cleaned up but I figure it a) doesn't > shine > a light on normal sketches and b) is cumbersome. Ultimately sketching is a > GUI tool and not sure it can be translated to code in an intuitive way. There is the concept of turtle graphics, like move forward 10, turn left 100 deg, move forward until y=3, etc. I implemented something like this and find it pretty useful. -- Sent from: http://forum.openscad.org/
JB
Jordan Brown
Tue, Aug 18, 2020 4:57 AM

[Sketch]

One could imagine having a way to describe a figure and its constraints
in the form of a data structure, and having a solver that would analyze
the data structure to find a figure that satisfies the constraints.

Something like:

poly = solve([
    [ ABS, 0, [0,0,0] ],         // Point 0 is at the origin
    [ REL, 1, 0, [10,0,0]],      // Point 1 is +10 X from point 0
    [ LENGTH, [1,2], [0,1], 2],  // The distance from point 1 to
                                 // point 2 is twice the distance
                                 // from point 0 to point 1.
    [ ANGLE, [0,1,2], 90 ],      // The angle between points 0, 1, and 2
                                 // is 90 degrees.
    [ ABS, 2, [undef,undef,0] ]  // Point 2 is on the Z=0 plane.
]);

I think there are two solutions to those constraints: 
[0,0,0]-[10,0,0]-[10,20,0] and [0,0,0]-[10,0,0]-[10,-20,0].  (Maybe only
the -Y one, if the ANGLE rule follows the right-hand-rule.)

I don't know how hard it is to create such a solver.  (It would depend
of course on what rules are allowed.)  Probably too hard for me.

I don't know whether anybody would really be interested in such a thing
in OpenSCAD.

> [Sketch] One could imagine having a way to describe a figure and its constraints in the form of a data structure, and having a solver that would analyze the data structure to find a figure that satisfies the constraints. Something like: poly = solve([ [ ABS, 0, [0,0,0] ], // Point 0 is at the origin [ REL, 1, 0, [10,0,0]], // Point 1 is +10 X from point 0 [ LENGTH, [1,2], [0,1], 2], // The distance from point 1 to // point 2 is twice the distance // from point 0 to point 1. [ ANGLE, [0,1,2], 90 ], // The angle between points 0, 1, and 2 // is 90 degrees. [ ABS, 2, [undef,undef,0] ] // Point 2 is on the Z=0 plane. ]); I think there are two solutions to those constraints:  [0,0,0]-[10,0,0]-[10,20,0] and [0,0,0]-[10,0,0]-[10,-20,0].  (Maybe only the -Y one, if the ANGLE rule follows the right-hand-rule.) I don't know how hard it is to create such a solver.  (It would depend of course on what rules are allowed.)  Probably too hard for me. I don't know whether anybody would really be interested in such a thing in OpenSCAD.
I
irevdev
Tue, Aug 18, 2020 7:04 AM

That seems like a reasonable api JordanBrown, But yeah not sure if it suits
OpenScad.

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

That seems like a reasonable api JordanBrown, But yeah not sure if it suits OpenScad. -- Sent from: http://forum.openscad.org/
A
adrianv
Tue, Aug 18, 2020 1:03 PM

It seems like if you allow a specific limited class of rules that operate
sequentially then it is not hard to do this.  The point basically is that
for every rule you need to ask if you can solve the relevant equation it
implies.

This actually seems a lot like the turtle graphics concept but without the
turtle state or order:  at every step you create a new point based on a
previous point using some kind of instruction.  I am wondering whether this
scheme is significantly more powerful than my turtle implementation.  I
think the main possible source of extra power in this system is the ability
to refer back to previously generated points, but I can't tell if that
really lets you do anything different.

If you don't require a sequential process then it is going to get a lot
harder, because the equations will form a large coupled nonlinear system.  A
general solver might be able to find a solution, but finding all solutions
will be hard to do, and the process may not be robust.  And of course there
may be no solutions, or an infinite set of solutions.  If someone gave me
this capability as a black box, how would I use it?  It seems likely that
this is going to be hard to use as a practical tool for constructing shapes.

JordanBrown wrote

[Sketch]

One could imagine having a way to describe a figure and its constraints
in the form of a data structure, and having a solver that would analyze
the data structure to find a figure that satisfies the constraints.

Something like:

 poly = solve([
     [ ABS, 0, [0,0,0] ],         // Point 0 is at the origin
     [ REL, 1, 0, [10,0,0]],      // Point 1 is +10 X from point 0
     [ LENGTH, [1,2], [0,1], 2],  // The distance from point 1 to
                                  // point 2 is twice the distance
                                  // from point 0 to point 1.
     [ ANGLE, [0,1,2], 90 ],      // The angle between points 0, 1, and

2
// is 90 degrees.
[ ABS, 2, [undef,undef,0] ]  // Point 2 is on the Z=0 plane.
]);

I think there are two solutions to those constraints: 
[0,0,0]-[10,0,0]-[10,20,0] and [0,0,0]-[10,0,0]-[10,-20,0].  (Maybe only
the -Y one, if the ANGLE rule follows the right-hand-rule.)

I don't know how hard it is to create such a solver.  (It would depend
of course on what rules are allowed.)  Probably too hard for me.

I don't know whether anybody would really be interested in such a thing
in OpenSCAD.


OpenSCAD mailing list

Discuss@.openscad

It seems like if you allow a specific limited class of rules that operate sequentially then it is not hard to do this. The point basically is that for every rule you need to ask if you can solve the relevant equation it implies. This actually seems a lot like the turtle graphics concept but without the turtle state or order: at every step you create a new point based on a previous point using some kind of instruction. I am wondering whether this scheme is significantly more powerful than my turtle implementation. I think the main possible source of extra power in this system is the ability to refer back to previously generated points, but I can't tell if that really lets you do anything different. If you don't require a sequential process then it is going to get a lot harder, because the equations will form a large coupled nonlinear system. A general solver might be able to find a solution, but finding all solutions will be hard to do, and the process may not be robust. And of course there may be no solutions, or an infinite set of solutions. If someone gave me this capability as a black box, how would I use it? It seems likely that this is going to be hard to use as a practical tool for constructing shapes. JordanBrown wrote >> [Sketch] > > One could imagine having a way to describe a figure and its constraints > in the form of a data structure, and having a solver that would analyze > the data structure to find a figure that satisfies the constraints. > > Something like: > > poly = solve([ > [ ABS, 0, [0,0,0] ], // Point 0 is at the origin > [ REL, 1, 0, [10,0,0]], // Point 1 is +10 X from point 0 > [ LENGTH, [1,2], [0,1], 2], // The distance from point 1 to > // point 2 is twice the distance > // from point 0 to point 1. > [ ANGLE, [0,1,2], 90 ], // The angle between points 0, 1, and > 2 > // is 90 degrees. > [ ABS, 2, [undef,undef,0] ] // Point 2 is on the Z=0 plane. > ]); > > I think there are two solutions to those constraints:  > [0,0,0]-[10,0,0]-[10,20,0] and [0,0,0]-[10,0,0]-[10,-20,0].  (Maybe only > the -Y one, if the ANGLE rule follows the right-hand-rule.) > > I don't know how hard it is to create such a solver.  (It would depend > of course on what rules are allowed.)  Probably too hard for me. > > I don't know whether anybody would really be interested in such a thing > in OpenSCAD. > > > _______________________________________________ > OpenSCAD mailing list > Discuss@.openscad > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org -- Sent from: http://forum.openscad.org/
JB
Jordan Brown
Wed, Aug 19, 2020 4:21 PM

On 8/18/2020 6:03 AM, adrianv wrote:

It seems like if you allow a specific limited class of rules that operate
sequentially then it is not hard to do this.  The point basically is that
for every rule you need to ask if you can solve the relevant equation it
implies.

This actually seems a lot like the turtle graphics concept but without the
turtle state or order:  at every step you create a new point based on a
previous point using some kind of instruction.  I am wondering whether this
scheme is significantly more powerful than my turtle implementation.  I
think the main possible source of extra power in this system is the ability
to refer back to previously generated points, but I can't tell if that
really lets you do anything different.

If you don't require a sequential process then it is going to get a lot
harder, because the equations will form a large coupled nonlinear system.  A
general solver might be able to find a solution, but finding all solutions
will be hard to do, and the process may not be robust.  And of course there
may be no solutions, or an infinite set of solutions.  If someone gave me
this capability as a black box, how would I use it?  It seems likely that
this is going to be hard to use as a practical tool for constructing shapes.

What I was intending to describe - and what I think these tools do -
is the latter.  I wrote out the rules more or less sequentially, because
that's how I was mentally constructing the figure, but the intent was
that they were an unordered set of constraints on the various points.

It's a very different way of thinking of design from the much more
concrete "transform a shape" model that OpenSCAD uses.

As I said, it's not clear to me that there would be an audience for it
in the OpenSCAD context.  I was just trying to describe how a tool like
this could be carried over to an OpenSCAD environment.

On 8/18/2020 6:03 AM, adrianv wrote: > It seems like if you allow a specific limited class of rules that operate > sequentially then it is not hard to do this. The point basically is that > for every rule you need to ask if you can solve the relevant equation it > implies. > > This actually seems a lot like the turtle graphics concept but without the > turtle state or order: at every step you create a new point based on a > previous point using some kind of instruction. I am wondering whether this > scheme is significantly more powerful than my turtle implementation. I > think the main possible source of extra power in this system is the ability > to refer back to previously generated points, but I can't tell if that > really lets you do anything different. > > If you don't require a sequential process then it is going to get a lot > harder, because the equations will form a large coupled nonlinear system. A > general solver might be able to find a solution, but finding all solutions > will be hard to do, and the process may not be robust. And of course there > may be no solutions, or an infinite set of solutions. If someone gave me > this capability as a black box, how would I use it? It seems likely that > this is going to be hard to use as a practical tool for constructing shapes. What I was intending to describe - and what I *think* these tools do - is the latter.  I wrote out the rules more or less sequentially, because that's how I was mentally constructing the figure, but the intent was that they were an unordered set of constraints on the various points. It's a very different way of thinking of design from the much more concrete "transform a shape" model that OpenSCAD uses. As I said, it's not clear to me that there would be an audience for it in the OpenSCAD context.  I was just trying to describe how a tool like this could be carried over to an OpenSCAD environment.