Learning how to use OpenSCAD

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

lostapathy
On 2/20/19 6:19 PM, adrianv wrote:
boxcarmib wrote
I suggest that a useful first step might be legitimizing what libraries
are currently available by adding them to the OpenSCAD User Manual… as say
Chapter 10. That way at least those are aren’t adverse to RTFM would see
that libraries are not simply routines of unknown providence showing up on
Thingiverse.
If there’s support for this first step I’d be happy to start said Chapter
10 and populating it with what I can gather from the existing library
code.
This sounds like a great idea.  The only question I have---having not
examined the libraries in question---is whether they are good libraries.  Is
the API well thought out.  I don't want to put up roadblocks to progress,
but you want to get things off to a good start.       
This is why a package manager that supports versioning is so critical, and why I think the libraries should exist independently of OpenSCAD itself.

If we enshrine any current library as official and ship it with OpenSCAD itself, it becomes impossible to update it and improve the API on a separate lifecycle from OpenSCAD (which is itself another can of worms).  It also becomes fairly unpalatable to make major breaking changes to the API.  See the inconsistent APIs in MCAD that would be easy to make better, but in doing so would break all existing code that uses them.

Where if the libraries are independent, and the package manager can handle version dependencies, it's ok to change the API between MCAD 1.0 and MCAD 2.0, so long as your own project's manifest (scadfile in the case of scad_bundler) knows what version it needs.

Further, there seems to be a growing trend in other languages to minimize the size of the "standard library" for these reasons, and also so obsolete libraries can be abandoned.  For example, in the Ruby standard library, there are a lot of libraries that should really be removed from standard library because they are unmaintained and largely irrelevant for new code, but people don't want to break existing code by removing them.

I went into some of this from other angles in my article at https://lostapathy.com/blog/openscad-needs-a-package-manager/ before I released scad_bundler at https://github.com/lostapathy/scad_bundler

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

lostapathy
In reply to this post by boxcarmib
On 2/20/19 6:34 PM, Hugo Jackson wrote:
As per this discussion I’ve been spending the afternoon looking at the existing libraries and I would say they are of mixed quality, so part of the work I’d be willing to undertake would be to refactor most of them, and subject their modification to whatever the general review process is for code enhancements.
There are a number of libraries that really should be folded together… there’s a least 3 “shape” libraries, some of which have overlapping functionally, and some that have modules that just don’t work, not to mention libraries that haven’t been worked on in years so they bring up “assign deprecated” and other similar errors.
 I’ve used source control in many forms but not GitHub and I don’t know what the protocol and procedures would be for submitting proposed changes and the release mechanism, so I’d need a little handholding help with that… perhaps there’s some already overworked code developer maintainer who could shoot me an offer to help me get bootstrapped into “how to submit changes to the OpenSCAD master branch”.

See my other reply from farther up thread as to why I don't think more libraries in OpenSCAD proper is the answer.

Also as you look at package up libraries, keep in mind that we need to be respectful of the original author's copyright and license, which is often not totally clear, and it may not always be possible to combine libraries that were released under different licenses.

There's probably a lot to be said for taking existing libraries, figuring out what useful functionality they contain, and then making clean implementations with a 100% known license situation.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

RobWLakes
Just to add some alternative material at the very simple level, I have uploaded some OpenSCAD worksheets for lower to middle high school students. They are meant to be almost self explanatory and incorporate assessment points for teachers. However they could be just as useful in "code clubs" for young people or older folk who are not confident with 3-D geometry, maths etc.

https://www.thingiverse.com/thing:2759515

The number of views matches the downloads, so I am assuming that people who view the project, quite like the concept. Certainly not heavyweight material, but hopefully people will find it useful and help spread the OpenSCAD message. OpenSCAD is a very powerful educational experience. Its design, computational, and practical outcomes (in 3-D printing) are very hard to beat.

BTW, the range of topics and responses has been excellent lately.
Cheers, RobW
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach,
Victoria, Australia
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

nophead
So that's confirmation that nothing surprising has happened. 
 
vertex 6.12323e-17 1 0  

I fixed those silly numbers in my PR here that is merged into master:  https://github.com/openscad/openscad/pull/2669

I don't think OpenSCAD needs package managers and namespaces, etc. The number of libraries needed is very small compared to general purpose programming languages. I don't use any but the amount of code I use that would perhaps belong in a standard library is tiny. A one page of matrix maths functions, Bezier curves and a sweep. I have a few standard shapes like sectors, rounded rectangles and teardrops but they are trivial to write. 

I like OpenSCAD because it is simply and light weight compared to something like C++ that needs many gigabytes of libraries to get anything done nowadays.

On Thu, 21 Feb 2019 at 06:14, Rob Ward <[hidden email]> wrote:
Just to add some alternative material at the very simple level, I have uploaded some OpenSCAD worksheets for lower to middle high school students. They are meant to be almost self explanatory and incorporate assessment points for teachers. However they could be just as useful in "code clubs" for young people or older folk who are not confident with 3-D geometry, maths etc.

https://www.thingiverse.com/thing:2759515

The number of views matches the downloads, so I am assuming that people who view the project, quite like the concept. Certainly not heavyweight material, but hopefully people will find it useful and help spread the OpenSCAD message. OpenSCAD is a very powerful educational experience. Its design, computational, and practical outcomes (in 3-D printing) are very hard to beat.

BTW, the range of topics and responses has been excellent lately.
Cheers, RobW_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

adrianv
nophead wrote

> I don't think OpenSCAD needs package managers and namespaces, etc. The
> number of libraries needed is very small compared to general purpose
> programming languages. I don't use any but the amount of code I use that
> would perhaps belong in a standard library is tiny. A one page of matrix
> maths functions, Bezier curves and a sweep. I have a few standard shapes
> like sectors, rounded rectangles and teardrops but they are trivial to
> write.
>
> I like OpenSCAD because it is simply and light weight compared to
> something
> like C++ that needs many gigabytes of libraries to get anything done
> nowadays.

How do we know today what the libraries of tomorrow might be?  It seems like
there's a gear library, which sounds useful at least in general.   There was
a library I saw that involved defining attachment points and connecting
parts together that seems potentially useful.  (But I don't know if it is
actually useful.) There really should be something for doing fillets and
roundovers.  I am not sure what the right form is for this kind of thing.
One approach would be things like a cylinder that flares in or out at one or
both ends, which would enable filleted or rounded over junctions or holes.  
Shapes like this are not so easy to make, and it's not immediately obvious
how to design a clean API for this.  

I do think that at least initially, libraries can be established without a
package manager.  It's not clear to me how important the package manager is.
But it is definitely a good idea to keep them separate from OpenSCAD itself.
It should be possible to update individual libraries independently and as
needed.  We should give libraries clear version numbers and make versioning
clear so that libraries can evolve.   Perhaps libraries should define a
variable that gives the library version?  

When C was originally invented it was small and simple.  Did Kernighan and
Ritchie foresee its eventual destination?   There were people who insisted
that it was better to write in assembly language rather than C.  Simpler?
Well, sort of.  OpenSCAD is simple, as long as your design is simple.  But
if your design is more complex, then the OpenSCAD code is not so simple.
That's the role for libraries---to make it easier to consider more complex
designs, to actually build more complex things, and to make it easier to
maintain your code.  



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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

RevarBat


On Feb 21, 2019, at 7:26 AM, adrianv <[hidden email]> wrote:

How do we know today what the libraries of tomorrow might be?  It seems like
there's a gear library, which sounds useful at least in general.   There was
a library I saw that involved defining attachment points and connecting
parts together that seems potentially useful.  (But I don't know if it is
actually useful.) There really should be something for doing fillets and
roundovers.  I am not sure what the right form is for this kind of thing.
One approach would be things like a cylinder that flares in or out at one or
both ends, which would enable filleted or rounded over junctions or holes.  
Shapes like this are not so easy to make, and it's not immediately obvious
how to design a clean API for this.  

All these, except attachments, actually already exist in the BOSL library.  And I'm thinking about how to best implement attachments.


- Revar


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

adrianv
The BOSL library looks very good, and it's great that it's documented.   I
started trying to use it and so far have the following observations.  

I have been finding it useful to define a cube by its corner coordinates.
It doesn't supply this, as far as I could see.  

There are a whole bunch of cube functions that make cubes in different
places, and then separate functions that make rounded cubes.  It seems like
it might be better to have this be unified, so you can create rounded cubes
in any desired manner.  In other words, rounding would be an option, or cube
positioning would be an option.  Or there might be a master cube module that
can make any kind of cube and more restricted functions that are simpler
that make specific ones.  

I wanted to specify the inner diameter of a tube.  This seems like it would
be very common--maybe even the most common way to make a tube.  Having to
specify ID+wall and then wall again is clumsy.  

The last concern has to do with the use of the term "fillet" and the
functionality I meant when I used the term.  I may not understand general
usage here.  I understood the term "fillet" to refer to specifically
rounding of *concave" corners.   Wikipedia presents this as the primary
definition:  https://en.wikipedia.org/wiki/Fillet_(mechanics)

What is implemented in BOSL as "fillet" is what I would call a roundover.
Now I poked around and found that some other programs (e.g. Autocad) use the
term "fillet" to mean roundover.  So some sort of decision on nomenclature
is necessary.  But also, the BOSL library appears to lack the ability to do
the type of fillet I was referring to, at least in general.  There are some
special cases such as the thinning brace and thinning wall.  

<http://forum.openscad.org/file/t2477/fillet2.png>

One other observation about the BOSL library:  it's not listed on the
OpenSCAD list of libraries.  


RevarBat wrote
>> On Feb 21, 2019, at 7:26 AM, adrianv &lt;

> avm4@

> &gt; wrote:
>>
> There really should be something for doing fillets and
>> roundovers.  I am not sure what the right form is for this kind of thing.
>> One approach would be things like a cylinder that flares in or out at one
>> or
>> both ends, which would enable filleted or rounded over junctions or
>> holes.  
>> Shapes like this are not so easy to make, and it's not immediately
>> obvious
>> how to design a clean API for this.  
>
> All these, except attachments, actually already exist in the BOSL library.
> And I'm thinking about how to best implement attachments.





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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

adrianv
In reply to this post by JordanBrown
JordanBrown wrote
> If you go to openscad.org, then "documentation", then (in the left
> sidebar or scroll down), "Tutorials - Articles / Blogs", it's the first
> link.  It was the first thing I saw and read.  It could be more
> prominent, but not much.

I have taken a look at the various tutorials to see if I missed anything and
offer here a brief remark on each.  

The first one I already read.  It is great because it gives some ideas of
how to really make use of modules.  

The second one is a dead link.

The third one (EduTechWiki) is basically a rehash of the manual with some
examples.  I would say it's sort of unfortunate in that it shows the
creation of a lego block in an rather ugly fashion.  The code examples are a
bit much to actually read through.   Perhaps if it proceeded onward to show
a rewrite using more general modules I'd think it more helpful.  

The fourth one by Ragain about DXF is missing a bunch of the pictures for
me, which makes it hard to follow.  

The fifth one, "I Heart Robots" has some interesting content.  It's actually
a collection of several posts.  There is one on DXF again.  But also another
one about rounding.   It also shows the need for a generic rounded polygon
function.   The author works pretty hard to round over one corner of a
triangle.  Has anybody written this?

The sixth one refers to the Obijuan library and the use of connectors to do
beveling.  It looks interesting, but it's a bit spare on details.  It seems
like this notion of connectors is useful, though.  

The last HTML tutorial is another one about DXF import, which looks useful.  






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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

RevarBat
In reply to this post by adrianv


On Feb 23, 2019, at 8:43 AM, adrianv <[hidden email]> wrote:

The BOSL library looks very good, and it's great that it's documented.   I
started trying to use it and so far have the following observations.  

I have been finding it useful to define a cube by its corner coordinates.
It doesn't supply this, as far as I could see.  

Good idea.  I've added `cube2pt(p1,p2)` to implement this.


There are a whole bunch of cube functions that make cubes in different
places, and then separate functions that make rounded cubes.  It seems like
it might be better to have this be unified, so you can create rounded cubes
in any desired manner.  In other words, rounding would be an option, or cube
positioning would be an option.  Or there might be a master cube module that
can make any kind of cube and more restricted functions that are simpler
that make specific ones.  

Yeah, the set of cube modules were evolved over time and it shows.  I'll take look at
this and decide what to do.  Maybe take offsetcube(), rename it something more
generic like `cuboid()` and give it `align`, `fillet` and `chamfer` arguments.


I wanted to specify the inner diameter of a tube.  This seems like it would
be very common--maybe even the most common way to make a tube.  Having to
specify ID+wall and then wall again is clumsy.  

I've updated tube() to be able to take inner and outer diams and radii, or `wall` with
either inner or outer diams/radii.  The following calls should all create the same tube shape.

- tube(h=10, r=50, ir=45);
- tube(h=10, d=100, id=90);
- tube(h=10, r=50, wall=5);
- tube(h=10, d=100, wall=5);
- tube(h=10, ir=45, wall=5);
- tube(h=10, id=90, wall=5);


The last concern has to do with the use of the term "fillet" and the
functionality I meant when I used the term.  I may not understand general
usage here.  I understood the term "fillet" to refer to specifically
rounding of *concave" corners.   Wikipedia presents this as the primary
definition:  https://en.wikipedia.org/wiki/Fillet_(mechanics)

Err, Wikipedia defines a fillet as

    "In mechanical engineering, a fillet is a rounding of an _interior or exterior_ corner of a part design."

However, dictionary.com indicates a fillet is a rounding of an interior corner.

AutoCAD uses fillet for both interior and exterior corners.

I figure if it's good enough for AutoCAD and Wikipedia, it's a generally understood name for interior and exterior angle rounding.


What is implemented in BOSL as "fillet" is what I would call a roundover.
Now I poked around and found that some other programs (e.g. Autocad) use the
term "fillet" to mean roundover.  So some sort of decision on nomenclature
is necessary.  But also, the BOSL library appears to lack the ability to do
the type of fillet I was referring to, at least in general.  There are some
special cases such as the thinning brace and thinning wall.  

I actually hadn't noticed this until you mentioned it.  I've added `interior_fillet()` to `shapes.scad` to provide this capability, for arbitrary interior angles.


One other observation about the BOSL library:  it's not listed on the
OpenSCAD list of libraries.  

Would you believe that I simply hadn't noticed that page was a Wiki I could add to?

- Revar







_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

adrianv
RevarBat wrote
>> On Feb 23, 2019, at 8:43 AM, adrianv &lt;

> avm4@

> &gt; wrote:
>>
>> The BOSL library looks very good, and it's great that it's documented.  
>> I
>> started trying to use it and so far have the following observations.  
>>
>> I have been finding it useful to define a cube by its corner coordinates.
>> It doesn't supply this, as far as I could see.  
>
> Good idea.  I've added `cube2pt(p1,p2)` to implement this.

I realized that I actually mis-wrote what I did.  I defined the cube by
ranges of x, y, and z.    My function is boundcube(xrange, yrange, zrange).
Does this difference matter?  I think it does.  I went on to define an
"infinity" called inf, and "all" as [-inf,inf] so I could define half-spaces
like boundcube([0,inf],all,all).  This is less natural with the two points
method.  Maybe both approaches should be provided?  I think my thinking
process also tended to be about the x, y and z ranges, and not about the
corner points---like I need to fill in this space from this x position to
that one.    

Is this a reasonable way to design shapes?  Is there a downside to creating
large coordinates, like setting inf=10^4 or 10^5?  When I did my sliding
dovetails I made them by using halfspaces defined like this, rotating them,
and then doing intersections and unions.  Is there a better way?    



>> There are a whole bunch of cube functions that make cubes in different
>> places, and then separate functions that make rounded cubes.  It seems
>> like
>> it might be better to have this be unified, so you can create rounded
>> cubes
>> in any desired manner.  In other words, rounding would be an option, or
>> cube
>> positioning would be an option.  Or there might be a master cube module
>> that
>> can make any kind of cube and more restricted functions that are simpler
>> that make specific ones.  
>
> Yeah, the set of cube modules were evolved over time and it shows.  I'll
> take look at
> this and decide what to do.  Maybe take offsetcube(), rename it something
> more
> generic like `cuboid()` and give it `align`, `fillet` and `chamfer`
> arguments.

Sounds like that could be a reasonable approach.  Will fillet and chamfer
have interior and exterior options?  


>> I wanted to specify the inner diameter of a tube.  This seems like it
>> would
>> be very common--maybe even the most common way to make a tube.  Having to
>> specify ID+wall and then wall again is clumsy.  
>
> I've updated tube() to be able to take inner and outer diams and radii, or
> `wall` with
> either inner or outer diams/radii.  The following calls should all create
> the same tube shape.
>
> - tube(h=10, r=50, ir=45);
> - tube(h=10, d=100, id=90);
> - tube(h=10, r=50, wall=5);
> - tube(h=10, d=100, wall=5);
> - tube(h=10, ir=45, wall=5);
> - tube(h=10, id=90, wall=5);

Looks good to me.  I know there's already a ton of parameters, but is it
worth adding od as an option for outer diameter for consistency?  


>> The last concern has to do with the use of the term "fillet" and the
>> functionality I meant when I used the term.  I may not understand general
>> usage here.  I understood the term "fillet" to refer to specifically
>> rounding of *concave" corners.   Wikipedia presents this as the primary
>> definition:  https://en.wikipedia.org/wiki/Fillet_(mechanics)
>> &lt;https://en.wikipedia.org/wiki/Fillet_(mechanics)&gt;
>
> Err, Wikipedia defines a fillet as
>
>     "In mechanical engineering, a fillet is a rounding of an _interior or
> exterior_ corner of a part design."
>
> However, dictionary.com &lt;http://dictionary.com/&gt; indicates a fillet
> is a rounding of an interior corner.

Yeah,  Wikipedia does define it as including exterior.  But then they give
only examples of interior rounding.  Also the word "fillet" refers to "a
strip of material", so an added strip in a transition, not to removal.  


> AutoCAD uses fillet for both interior and exterior corners.
>
> I figure if it's good enough for AutoCAD and Wikipedia, it's a generally
> understood name for interior and exterior angle rounding.

Well, maybe, but maybe not.  I noticed in watching autocad tutorials a
couple things.  One is that there is one button.  So they wanted one term...
Well, except they didn't.  the button is labeled "rounds and fillets edges".
This suggests that rounds and fillets are not the same.  

A second observation is that almost all the tutorials are in 2d operating on
lines, where in fact there is no difference.  

A third observation is that if you are operating on a 3d shape by selecting
edges, as one does in autocad, the program knows if it's concave or convex,
so it would be silly to have two functions for this.  

So the autocad designers may have chosen to generalize "fillet" beyond its
normal meaning.  Since autocad is important, this broadened the term.  But
does OpenSCAD work the same way as autocad?  

Nope.  We have to explicitly distinguish between exterior and interior
operations.  So the question is how will that be done.  I'm not insisting
that fillet is the wrong term here, but just make sure that people are
generally happy with the choice of terms.  It may also depend on how you do
things.  


>> What is implemented in BOSL as "fillet" is what I would call a roundover.
>> Now I poked around and found that some other programs (e.g. Autocad) use
>> the
>> term "fillet" to mean roundover.  So some sort of decision on
>> nomenclature
>> is necessary.  But also, the BOSL library appears to lack the ability to
>> do
>> the type of fillet I was referring to, at least in general.  There are
>> some
>> special cases such as the thinning brace and thinning wall.  
>
> I actually hadn't noticed this until you mentioned it.  I've added
> `interior_fillet()` to `shapes.scad` to provide this capability, for
> arbitrary interior angles.

This is a start.  I have a few thoughts.  One is that interior filletting
should be possible on cubes and cylinders just the way you have
filleted_cylinder().  In fact, I might want to make a cylinder that is
interior filleted on one end and exterior filleted on the other, so the
object includes both fillets.  This way if I want to make a stopped hole I
can simply create the cylinder and subtract it from a cube and I have all of
my rounding handled effortlessly.   (This is possible now but I think you
need to use 3 objects to do it.)  

Another thing is that there needs to be a way to make the corner interior
fillets for a cube.  In the

https://github.com/StephS/i2_xends/blob/master/inc/fillets.scad

library you can make the corners.  Actually for roundover masks perhaps you
need a way to mask off corners.  And stepping back, I am still not really
sure how to apply these kind of building blocks in complex situations.   I
made a shape over the weekend that had a rectangular base that tapered wider
as it went up.  I needed the bottom corner to be rounded over.  That seemed
very difficult to do because it was an obtuse angle and I didn't know what
the angle was---and the fillet mask doesn't have an angle option.   I did a
chamfer instead.  This required trial and error shifting the chamfer mask
around so that I didn't have a little corner.   None of this is satisfying.
If I make a shape using prismoid and want to round the bottom I don't want
to have to do a bunch of trig to figure out the angles.  

The second observation is that if you're going to say interior_fillet then
you need to say exterior_fillet for the other case for consistency.   The
chamfer operation actually has this problem as well, in that you need
interior and exterior chamfers if you want to supply them on cubes or
cylinders.  I kind of like the term "flare" to refer to adding interior
angle chamfers or interior fillets to the edges of cubes.  In other words,
you specify a flared cylinder end and then somehow indicate whether you want
it rounded or chamfered.      
One possible way to do this might be to make a data structure that describes
edge treatments and have functions that create the data structure with
different characteristics and defaults.    

So what is the right language for OpenSCAD (not autocad) to use to capture
all of this stuff.  And what are the right functions and operations to make
it easy to do?  

The others who have written on this thread about libraries, do you have any
thoughts about the BOSL library?  It appears much better than MCAD to me in
general.   What does MCAD have that is missing from BOSL?   Does it make
sense to give BOSL a section in the OpenSCAD manual?   Does anybody else
have any thoughts on how to improve BOSL and make it something you'd be
happy to use?  

I mentioned in an earlier post that generalized polygon roundover seems like
a nice feature.  And it turns out it does exist, already done, just like
BOSL was out there kind of in hiding.  
https://github.com/Irev-Dev/Round-Anything
There was a thread about a year ago about this.  This library also supplies
a minkowski rounding function that could be useful in cases where it's not
too slow to use.   Hmmm.  Assuming there are any such cases.   (The author
speaks of waiting 10 hours for the result.)   I just ran it on a simple test
case and am still waiting, which doesn't inspire a whole lot of excitement,
though I suppose if I could get my model to a finished state and then run
this for an hour to apply the rounding it might still be useful.    It took
25 seconds to round over a cube with $fn=8.  I took a look at the code and
it calls minkowski three times.   There's also a round2d based on offset()
which rounds any 2d object and runs in reasonable time, so that could be
useful.  

My simple test case finally finished.  It took 30 minutes and this is the
result:  
<http://forum.openscad.org/file/t2477/round.png>

Another question I had is what is the standard way to use a library like
this.  I have put it in a lib directory (as a subdirectory of where my work
is) so I'm doing stuff like

use <lib/bosl/shapes.scad>

Is that the right thing to do?  Ideally I should be able to share my code
with other people and they should be able to run it without having to tinker
with the use statements.  



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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

tjhowse
I made this tutorial video a few years ago. People seem to like it: https://www.youtube.com/watch?v=_2r9bWsVwdM


On Tue, 26 Feb 2019 at 01:26, adrianv <[hidden email]> wrote:
RevarBat wrote
>> On Feb 23, 2019, at 8:43 AM, adrianv &lt;

> avm4@

> &gt; wrote:
>>
>> The BOSL library looks very good, and it's great that it's documented. 
>> I
>> started trying to use it and so far have the following observations. 
>>
>> I have been finding it useful to define a cube by its corner coordinates.
>> It doesn't supply this, as far as I could see. 
>
> Good idea.  I've added `cube2pt(p1,p2)` to implement this.

I realized that I actually mis-wrote what I did.  I defined the cube by
ranges of x, y, and z.    My function is boundcube(xrange, yrange, zrange).
Does this difference matter?  I think it does.  I went on to define an
"infinity" called inf, and "all" as [-inf,inf] so I could define half-spaces
like boundcube([0,inf],all,all).  This is less natural with the two points
method.  Maybe both approaches should be provided?  I think my thinking
process also tended to be about the x, y and z ranges, and not about the
corner points---like I need to fill in this space from this x position to
that one.     

Is this a reasonable way to design shapes?  Is there a downside to creating
large coordinates, like setting inf=10^4 or 10^5?  When I did my sliding
dovetails I made them by using halfspaces defined like this, rotating them,
and then doing intersections and unions.  Is there a better way?   



>> There are a whole bunch of cube functions that make cubes in different
>> places, and then separate functions that make rounded cubes.  It seems
>> like
>> it might be better to have this be unified, so you can create rounded
>> cubes
>> in any desired manner.  In other words, rounding would be an option, or
>> cube
>> positioning would be an option.  Or there might be a master cube module
>> that
>> can make any kind of cube and more restricted functions that are simpler
>> that make specific ones. 
>
> Yeah, the set of cube modules were evolved over time and it shows.  I'll
> take look at
> this and decide what to do.  Maybe take offsetcube(), rename it something
> more
> generic like `cuboid()` and give it `align`, `fillet` and `chamfer`
> arguments.

Sounds like that could be a reasonable approach.  Will fillet and chamfer
have interior and exterior options? 


>> I wanted to specify the inner diameter of a tube.  This seems like it
>> would
>> be very common--maybe even the most common way to make a tube.  Having to
>> specify ID+wall and then wall again is clumsy. 
>
> I've updated tube() to be able to take inner and outer diams and radii, or
> `wall` with
> either inner or outer diams/radii.  The following calls should all create
> the same tube shape.
>
> - tube(h=10, r=50, ir=45);
> - tube(h=10, d=100, id=90);
> - tube(h=10, r=50, wall=5);
> - tube(h=10, d=100, wall=5);
> - tube(h=10, ir=45, wall=5);
> - tube(h=10, id=90, wall=5);

Looks good to me.  I know there's already a ton of parameters, but is it
worth adding od as an option for outer diameter for consistency? 


>> The last concern has to do with the use of the term "fillet" and the
>> functionality I meant when I used the term.  I may not understand general
>> usage here.  I understood the term "fillet" to refer to specifically
>> rounding of *concave" corners.   Wikipedia presents this as the primary
>> definition:  https://en.wikipedia.org/wiki/Fillet_(mechanics)
>> &lt;https://en.wikipedia.org/wiki/Fillet_(mechanics)&gt;
>
> Err, Wikipedia defines a fillet as
>
>     "In mechanical engineering, a fillet is a rounding of an _interior or
> exterior_ corner of a part design."
>
> However, dictionary.com &lt;http://dictionary.com/&gt; indicates a fillet
> is a rounding of an interior corner.

Yeah,  Wikipedia does define it as including exterior.  But then they give
only examples of interior rounding.  Also the word "fillet" refers to "a
strip of material", so an added strip in a transition, not to removal. 


> AutoCAD uses fillet for both interior and exterior corners.
>
> I figure if it's good enough for AutoCAD and Wikipedia, it's a generally
> understood name for interior and exterior angle rounding.

Well, maybe, but maybe not.  I noticed in watching autocad tutorials a
couple things.  One is that there is one button.  So they wanted one term...
Well, except they didn't.  the button is labeled "rounds and fillets edges".
This suggests that rounds and fillets are not the same.   

A second observation is that almost all the tutorials are in 2d operating on
lines, where in fact there is no difference. 

A third observation is that if you are operating on a 3d shape by selecting
edges, as one does in autocad, the program knows if it's concave or convex,
so it would be silly to have two functions for this. 

So the autocad designers may have chosen to generalize "fillet" beyond its
normal meaning.  Since autocad is important, this broadened the term.  But
does OpenSCAD work the same way as autocad? 

Nope.  We have to explicitly distinguish between exterior and interior
operations.  So the question is how will that be done.  I'm not insisting
that fillet is the wrong term here, but just make sure that people are
generally happy with the choice of terms.  It may also depend on how you do
things. 


>> What is implemented in BOSL as "fillet" is what I would call a roundover.
>> Now I poked around and found that some other programs (e.g. Autocad) use
>> the
>> term "fillet" to mean roundover.  So some sort of decision on
>> nomenclature
>> is necessary.  But also, the BOSL library appears to lack the ability to
>> do
>> the type of fillet I was referring to, at least in general.  There are
>> some
>> special cases such as the thinning brace and thinning wall. 
>
> I actually hadn't noticed this until you mentioned it.  I've added
> `interior_fillet()` to `shapes.scad` to provide this capability, for
> arbitrary interior angles.

This is a start.  I have a few thoughts.  One is that interior filletting
should be possible on cubes and cylinders just the way you have
filleted_cylinder().  In fact, I might want to make a cylinder that is
interior filleted on one end and exterior filleted on the other, so the
object includes both fillets.  This way if I want to make a stopped hole I
can simply create the cylinder and subtract it from a cube and I have all of
my rounding handled effortlessly.   (This is possible now but I think you
need to use 3 objects to do it.) 

Another thing is that there needs to be a way to make the corner interior
fillets for a cube.  In the

https://github.com/StephS/i2_xends/blob/master/inc/fillets.scad

library you can make the corners.  Actually for roundover masks perhaps you
need a way to mask off corners.  And stepping back, I am still not really
sure how to apply these kind of building blocks in complex situations.   I
made a shape over the weekend that had a rectangular base that tapered wider
as it went up.  I needed the bottom corner to be rounded over.  That seemed
very difficult to do because it was an obtuse angle and I didn't know what
the angle was---and the fillet mask doesn't have an angle option.   I did a
chamfer instead.  This required trial and error shifting the chamfer mask
around so that I didn't have a little corner.   None of this is satisfying.
If I make a shape using prismoid and want to round the bottom I don't want
to have to do a bunch of trig to figure out the angles. 

The second observation is that if you're going to say interior_fillet then
you need to say exterior_fillet for the other case for consistency.   The
chamfer operation actually has this problem as well, in that you need
interior and exterior chamfers if you want to supply them on cubes or
cylinders.  I kind of like the term "flare" to refer to adding interior
angle chamfers or interior fillets to the edges of cubes.  In other words,
you specify a flared cylinder end and then somehow indicate whether you want
it rounded or chamfered.     
One possible way to do this might be to make a data structure that describes
edge treatments and have functions that create the data structure with
different characteristics and defaults.   

So what is the right language for OpenSCAD (not autocad) to use to capture
all of this stuff.  And what are the right functions and operations to make
it easy to do? 

The others who have written on this thread about libraries, do you have any
thoughts about the BOSL library?  It appears much better than MCAD to me in
general.   What does MCAD have that is missing from BOSL?   Does it make
sense to give BOSL a section in the OpenSCAD manual?   Does anybody else
have any thoughts on how to improve BOSL and make it something you'd be
happy to use?   

I mentioned in an earlier post that generalized polygon roundover seems like
a nice feature.  And it turns out it does exist, already done, just like
BOSL was out there kind of in hiding. 
https://github.com/Irev-Dev/Round-Anything
There was a thread about a year ago about this.  This library also supplies
a minkowski rounding function that could be useful in cases where it's not
too slow to use.   Hmmm.  Assuming there are any such cases.   (The author
speaks of waiting 10 hours for the result.)   I just ran it on a simple test
case and am still waiting, which doesn't inspire a whole lot of excitement,
though I suppose if I could get my model to a finished state and then run
this for an hour to apply the rounding it might still be useful.    It took
25 seconds to round over a cube with $fn=8.  I took a look at the code and
it calls minkowski three times.   There's also a round2d based on offset()
which rounds any 2d object and runs in reasonable time, so that could be
useful. 

My simple test case finally finished.  It took 30 minutes and this is the
result: 
<http://forum.openscad.org/file/t2477/round.png>

Another question I had is what is the standard way to use a library like
this.  I have put it in a lib directory (as a subdirectory of where my work
is) so I'm doing stuff like

use <lib/bosl/shapes.scad>

Is that the right thing to do?  Ideally I should be able to share my code
with other people and they should be able to run it without having to tinker
with the use statements. 



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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Learning how to use OpenSCAD

adrianv
tjhowse wrote
> I made this tutorial video a few years ago. People seem to like it:
> https://www.youtube.com/watch?v=_2r9bWsVwdM

I'll admit that I didn't look at any of the tutorial videos I saw listed.  I
personally dislike the idea of video in general, and learning to write code
from a video seems insane.  That said, I did take a look at your video and
it seems like it's could be helpful to people who like that kind of thing.
You probably should have shown a method of designing the shape without
minkowski(), though---e.g. making the square and circle bigger by the width
using offset() to get the outside shape.  But there's nothing in your
tutorial that I didn't learn from reading the manual.  And yet there's much
to be learned that is not in the manual.  And that's what I'm talking about
here.  

My problem is not that I am trying to learn the basics.  I'm trying to
understand how to become an OpenSCAD *expert*. Are there multiple ways to
model something?  Is one better?  More elegant?  More efficient?  Or maybe
more importantly, how can I write code that I can still understand an hour
later?  How can I avoid struggling with getting elements in the model
oriented the right way and positioned correctly.    And also I'm trying to
understand how one avoids reinventing the wheel.  The more I dig around the
more it becomes apparent that standard practice in OpenSCAD is that
everybody does in fact just reinvent the wheel.

I'm going to start a new topic to try to better focus this discussion.  



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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12