Extending OpenSCAD from assembler to C or Perlish language and adding standard library
OpenSCAD as I know it today (2019) is very low level in terms of 3D
primitives (altough some libraries can alleviate this) and very high
level in terms of computer science, e.g. it supports fully dynamic
memory allocation with garbage collection). It is a good example of
a domain specific programming language done right.
Yet, there is scope for improvement:
-
There should be more convenience geometries supported natively rather than
through libraries or well known programming practises. -
The syntax and keywords, originally intended for communication, should
be abbreviated as to not burden model programmer excessively. In essence,
the ubiquitous "translate()" should somehow be abbreviated (our modest
suggestion is T() as already possible through module() interface, but
not formalized or suggested anywhere in the documentation). -
There should be a standard library of commonly needed objects, like
parametrized ergonometric human model or (metric) screws and nuts.
I am willing to program the features proposed below, but before I start
I want to know if they would be likely to be integrated to mainline
OpenSCAD. Or if I am reinventing a wheel. If my proposals already
exist, I would like to know about them and that documentation be
updated so that people like me would find them easily.
Here are the proposed new features
2 Shorthand
-
Make center=true the default (or settable as document global default)
-
Document conspiciously that PI constant (3.14) is supported, perhaps near description
of speacial variables like $fn -
translate() -> T(). As translate is the most common expression,
abbreviating it would be of capital importance. -
rotate() -> rot()
-
difference() -> diff()
-
cylinder() -> cyl()
-
Make the ca. 10 export options appear directly in the File menu so that cumbersome
access to submenu is not needed -
Add keyboard shortcut C-space for menu View -> Reset view
-
Add keyboard shortcut C-e for menu File -> Export as STL
- This is by far the most frequent and important export so it deserves the C-e abbreviation
- Add a command line flag to perform the export in batch mode
-
Add keyboard shortcut C-Shift-E for menu File -> Export as Image (PNG)
- Add a command line flag to perform the export in batch mode
-
Make Ctrl-+ work as zoom-in (in addition to C-])
-
Make Ctrl-- (minus) work as zoom-out (in addition to C-{)
3 New primitives
-
tube(), or add to cyl() a ~wall=X~ parameter, which, when supplied, would produce a tube
-
sqtube() to produce a square tube, as often found in furniture (and supplied by shops)
-
L() L-profile section as often supplied by shops and widely used in construction
-
U() U-profile section as often supplied by shops and widely used in construction
-
I() I-profile (aka H-profile) section as often supplied by shops and widely used in construction
-
In general add to cube(), cyl(), spehere(), and hull() a wall=X parameter,
which, when supplied, will produce a hollow version of the object -
prop() a special support structure for 3D additive printing. Essentially this would
be a tower that widens in the top (kind of like a yield sign triangle) -
tube_path() - Tube primitive that follows a 3D path of points (or even bezier). This
is already possible with linear_extrude() and hull() primitives using for() loop,
but it would be so much easier to understand (more documentative) if it was
first class primitive. -
sqtube_path()
-
hull_path()
-
bend(), stretch() and shear() transformations
4 Standard library
-
ergonometric human model
- allows studying models in terms of their scale to typical humans
- allows visualizing modesl with human mannequins
- standard human adult and child and parametrizable alternatives
-
set of screws, bolts, and nuts
- metric (and imperial?)
- different options for heads (sink, ball, etc.)
-
standard tools for cutting or mitering
5 Other improvements
-
Rounding the corners: Add to minkowski a way to avoid bloating
the original object by radius of the sphere, i.e. the outer dimensions
of the result of minkowski should be the same as the original object- Make corner-rounding with a sphere an argument of most primitives so
minkowski() need not be learned unless more sophisticated
application is needed
- Make corner-rounding with a sphere an argument of most primitives so
-
Add to cube() ability to make a pyramid or funnel by specifying
other end dimensions different from the starting end, kind of like
is possible with cylinder() using d1 and d2. Alternatively, leave
cube() alone, but provide pyramid() transform that can change cube()
or anything else, to pyramid like structure. -
X-ray tool in visualization: allows interactive movement of a cutting plane
to see inside objects (this is already possible noninteractively by
using a big cube to diff() a model) -
Automatic "drop to floor" feature that allows a set of objects (already
rotated to convenient position) to be dropped to common X-Y plane (i.e. to
have the same lowest Z). This is often needed when preparing a model with
many parts or objects for 3D printing. -
Coloring with patterns like wood grain (to show the intended orientation of the grain,
and that the object is to be made of wood)
Cheers,
--Sampo
I must say that I disagree with the proposed "shorthand". IMHO the single
biggest flaw in the C/C++ programming language is the unwillingness of the
original designers to use meaningful names for things. The multiple use of
the asterisk is particularly infuriating.
Regardless of what programming language is used, single character variable
names such as T are a nightmare when you want to find all the instances of a
variable.
And rather than change the underlying features of Openscad, just create
another program that does the hard work of creating Openscad code.
Just my 3 cents.
...R
--
Sent from: http://forum.openscad.org/
I totally agree that there's lots of room for improvement.
You give many good points. I'm seeing different ways to
solve some of those but having a solution would be great.
Looking at all the topics, that seems to be more work than
a full time developer could handle in a year. But we need
to start somewhere I guess.
If you'd like to help that would be awesome. For topics
that need code changes in OpenSCAD it can help to discuss
specifics in more detail on the IRC channel but there's
no such thing as an official process.
It's hard to tell in general what can be accepted, but if
you check the github history, there's quite a number of
contributions that were merged lately, notably the generic
tail recursion (https://github.com/openscad/openscad/pull/3020)
which is a very cool addition.
On 14.09.19 16:29, sampo-openscad19@zxid.org wrote:
There should be more convenience geometries supported natively
rather than through libraries or well known programming
practises.
Why? I don't see anything wrong with features being implemented
as a library. We have the problem that it's not easy to discover
and use libraries but I don't think the solution is to build
everything into the language because of that.
So instead of making the core bigger and bigger, solving the
other issues like library discovery and maybe also adding some
features the help implementing libraries may scale much better.
The syntax and keywords, originally intended for communication,
should be abbreviated as to not burden model programmer
excessively. In essence, the ubiquitous "translate()" should
somehow be abbreviated
People already are doing that using libraries, e.g. see
(https://www.thingiverse.com/thing:644830). The only way to
add short names to the core would be to support both long
and short form which is not ideal.
Apart from that, I think that is more a problem of getting
editor improvements. I also work a lot with Java code and
most of the existing code is not exactly known to use short
names. However I rarely ever type those. Modern IDEs generate
almost all of that via code completion or suggestions.
There should be a standard library of commonly needed objects,
like parametrized ergonometric human model or (metric) screws
and nuts.
There's a couple of libraries that already do a very good
job of that. However those might need some help. Specifically
BOLTS seems like an awesome effort with focus on standardized
mechanical components (like nuts and bolts). At this point
it looks like it's lacking people who continue working on
it (or care about the OpenSCAD part).
- Make center=true the default (or settable as document
global default)
I suspect the only way to do that without globally breaking
all existing designs is to create wrappers that can be
included when desired.
- Document conspiciously that PI constant (3.14) is supported,
perhaps near description of speacial variables like $fn
It's in the cheatsheet http://www.openscad.org/cheatsheet/
If it's missing in the manual, it should be added of cause.
- translate() -> T()
Does the "->" imply to change the name instead of adding new
features?
- Make the ca. 10 export options appear directly in the
File menu so that cumbersome access to submenu is not needed
I agree that the menu is not ideal. My suggestion would be
to fix that problem in a more general way though. Right now
there is no way of configuring keyboard shortcuts or the
toolbars. With that feature available, I would assume there's
hardly any need to go into the submenu anymore as I suspect
not many people actually use all of the options. Being able
to put the maybe 2 ones that are used often into the toolbar
and on shortcuts might be even a quicker way to access them.
On a separate note there's always the big issue that MacOS
is totally different regarding shortcuts causing collisions
and headaches all the time. Having that setup configurable
might help solving those issues too.
- Add keyboard shortcut C-space for menu View -> Reset view
C-space is the candidate for code completion. However
configurable shortcuts would solve that too.
- Add keyboard shortcut C-e for menu File -> Export as STL
Already used as shortcut. (Configurable shortcuts! :-)
- Add a command line flag to perform the export in
batch mode
Depending on what it means in detail, that should be not
very complicated (multiple file formats?).
- Add keyboard shortcut C-Shift-E for menu File -> Export
as Image (PNG)
That one is actually still free I think :).
- Add a command line flag to perform the export in
batch mode
I don't understand what that means.
- Make Ctrl-+ work as zoom-in (in addition to C-])
- Make Ctrl-- (minus) work as zoom-out (in addition to C-{)
Might be a bit tricky as it's currently grabbed by
the editor for font size changes. Not sure how often
that is used though.
3 New primitives
All except the transformations sound like a good fit
for one of the libraries (BOSL2?).
As for the transformations, those may need support from
the core, specifically to automatically subdivide the
mesh. Especially for bending there's a longer discussion
on github already. I suspect that's something a number
of people would like to see.
https://github.com/openscad/openscad/issues/815
...
Skipping the rest for as this is already quite long :-)
ciao,
Torsten.
On 2019-09-14 18:57, Torsten Paul wrote:
As for the transformations, those may need support from
the core, specifically to automatically subdivide the
mesh. Especially for bending there's a longer discussion
on github already. I suspect that's something a number
of people would like to see.
https://github.com/openscad/openscad/issues/815
Interesting 5 year old discussion on github.... as you say and the
comments there point out you need a (re-)meshing capability to produce
uniform mesh to do any sort of useful bending. Also, you need a way to
perform the object vertex transformations. Both of those capabilities
are still missing in OpenSCAD.
You can do both in AngelCAD though - also using an OpeSCAD STL as
starting point
https://gist.github.com/arnholm/af72c7d0790bb3d72e6bdf29c7aac1ed
Carsten Arnholm
Wrong, OpenSCAD can access the mesh just fine from a built-in
and that specifically was the proposal in the OP.
The restriction is only that this feature can not be implemented
as a library at this point.
But I guess the point was to get AngelCAD into the discussion
as it was not mentioned in this thread yet.
ciao,
Torsten.
Just wondering what type of user Openscad is aimed at?
I have been assuming the typical user is someone (like me) who wants to
create occasional models (most likely for 3D printing) and who does not have
enough "work" to justify the learning curve for Freecad, or the cost (and
learning curve) of any of the commercial CAD products.
I presume anyone working as a professional CAD designer will be using one of
the commercial products.
IMHO the nature of any extensions to the Openscad program (whether
internally, or as libraries) should have the typical user firmly in mind.
...R
--
Sent from: http://forum.openscad.org/
On 14.09.19 20:51, Robin2 wrote:
Just wondering what type of user Openscad is aimed at?
I'm not sure there is a clear answer to that. As far as I
know it was conceived as tool to help with designing RepRap
style 3d printers quite some years ago. So it started out as
an ad-hoc tool, not a designed language - that still shows
and probably always will be part of it.
It's not a commercial product so there's not some kind of
official target audience.
It's used for very interesting and fun things, including
education, math or even generating punching cards for knitting
machines
https://mathgrrl.com/hacktastic/2019/05/punch-card-knitting-machine-patterns-with-openscad/
One area where I'd like to see it improving is accessibility.
OpenSCAD is already used in some 3d printing workshops:
https://www.nypl.org/about/locations/heiskell/dimensions
I presume anyone working as a professional CAD designer will
be using one of the commercial products.
For designing things in industry applications, I would assume
that's the case. I personally don't see OpenSCAD competing in
that space anytime soon (or more likely that will never
happen, and that's fine).
However a professional designer might still decide using it
for smaller designs that can be easily shared and modified
by anyone without the need to buy expensive software available
only on Windows or signing in to cloud services imposing
random additional restrictions.
That said, there are examples of impressively huge projects
created with OpenSCAD (https://www.openscad.org/gallery.html).
IMHO the nature of any extensions to the Openscad program
(whether internally, or as libraries) should have the typical
user firmly in mind.
Yes, I totally agree with that.
ciao,
Torsten.
My two cents
2 Shorthand
- Make center=true the default
Disagree; it would break 99.99% of past code.
(or settable as document global default)
Possibly, but how do you control its scope, libraries written one way or the other for example.
- Document conspiciously that PI constant (3.14) is supported, perhaps near description
of speacial variables like $fn
It's a wiki, change it.
-
translate() -> T(). As translate is the most common expression,
abbreviating it would be of capital importance. -
rotate() -> rot()
-
difference() -> diff()
-
cylinder() -> cyl()
Try the snapshots, there is auto-complete, e.g. type 'tr(' -> 'translate('.
At times I agree about lots of typing, I have carpel tunnel and epicondylitis,
height= instead of h= in linear_extrude for example, let alone linear_extrude...
Sometimes I write my own abbreviations, you can quite easily do e.g.
module T(v) translate(v) children();
However, one of the things I like about OpenSCAD is its simplicity and easy of learning.
Using whole meaningful words means not having to remember what abbreviation or acronym to use.
If this was introduced you would need to support both, contaminating the language.
- Make the ca. 10 export options appear directly in the File menu so that cumbersome
access to submenu is not needed
https://github.com/openscad/openscad/issues/649
That is also a good example of different peoples work flow, and how little things can impact
different approaches.
- Add keyboard shortcut C-space for menu View -> Reset view
Agree a shortcut is needed, personally I'd suggest Ctrl-=
Also View/Center need one, perhaps Ctrl/Shft-= ??
Note, keys documented here https://github.com/openscad/openscad/wiki/Keyboard-Shortcuts
May be slightly out of date. It shows the Mac related peculiarities.
I agree with tp re customisable key layout, but some should be locked, e.g. F5/F6 as they have
become part of the language.
- Add keyboard shortcut C-e for menu File -> Export as STL
- This is by far the most frequent and important export so it deserves the C-e abbreviation
F7 too easy?? [added in 2019.05]
- Add a command line flag to perform the export in batch mode
Not following you.
- Add keyboard shortcut C-Shift-E for menu File -> Export as Image (PNG)
C-Shift-P?? (as I is taken)
- Add a command line flag to perform the export in batch mode
Not following you.
-
Make Ctrl-+ work as zoom-in (in addition to C-])
-
Make Ctrl-- (minus) work as zoom-out (in addition to C-{)
As mentioned, these are in the editor. Perhaps they could be freed-up if zoom icon(s) were
introduced?
3 New primitives
- tube(), or add to cyl() a ~wall=X~ parameter, which, when supplied, would produce a tube
I actually think this would be good (tube, not wall=) purely because it would be the most used
shape.
- sqtube() to produce a square tube, as often found in furniture (and supplied by shops)
Here you start getting issues, square tube in shops varies widely around the world, including
radius of corners. Same goes for profiles. That shouts 'library' to me.
-
L() L-profile section as often supplied by shops and widely used in construction
-
U() U-profile section as often supplied by shops and widely used in construction
-
I() I-profile (aka H-profile) section as often supplied by shops and widely used in
construction
- In general add to cube(), cyl(), spehere(), and hull() a wall=X parameter,
which, when supplied, will produce a hollow version of the object
I don't support this, with wall= it is no longer a cube or a cylinder.
Do you go further, define thickness for various walls and or have or not some end caps etc?
You'd be turning one tool into a swiss army knife, when you just want to butter bread.
- prop() a special support structure for 3D additive printing. Essentially this would
be a tower that widens in the top (kind of like a yield sign triangle)
No. That is a slicers job.
-
tube_path() - Tube primitive that follows a 3D path of points (or even bezier). This
is already possible with linear_extrude() and hull() primitives using for() loop,
but it would be so much easier to understand (more documentative) if it was
first class primitive. -
sqtube_path()
-
hull_path()
-
bend(), stretch() and shear() transformations
4 Standard library
- ergonometric human model
- allows studying models in terms of their scale to typical humans
- allows visualizing modesl with human mannequins
- standard human adult and child and parametrizable alternatives
Yes please. Animatable.
-
set of screws, bolts, and nuts
- metric (and imperial?)
- different options for heads (sink, ball, etc.)
-
standard tools for cutting or mitering
5 Other improvements
-
Rounding the corners: Add to minkowski a way to avoid bloating
the original object by radius of the sphere, i.e. the outer dimensions
of the result of minkowski should be the same as the original object- Make corner-rounding with a sphere an argument of most primitives so
minkowski() need not be learned unless more sophisticated
application is needed
- Make corner-rounding with a sphere an argument of most primitives so
-
Add to cube() ability to make a pyramid or funnel by specifying
other end dimensions different from the starting end, kind of like
is possible with cylinder() using d1 and d2. Alternatively, leave
cube() alone, but provide pyramid() transform that can change cube()
or anything else, to pyramid like structure.
- X-ray tool in visualization: allows interactive movement of a cutting plane
to see inside objects (this is already possible noninteractively by
using a big cube to diff() a model)
As the geometry is not calculated in preview, I suspect this can't be done.
- Automatic "drop to floor" feature that allows a set of objects (already
rotated to convenient position) to be dropped to common X-Y plane (i.e. to
have the same lowest Z). This is often needed when preparing a model with
many parts or objects for 3D printing.
As the geometry is not calculated in preview, I suspect this can't be done.
- Coloring with patterns like wood grain (to show the intended orientation of the grain,
and that the object is to be made of wood)
Complicated, as no doubt you want differences such as per face grain etc.
Cheers,
--Sampo
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This email has been checked for viruses by AVG.
https://www.avg.com
On 2019-09-14 19:59, Torsten Paul wrote:
Wrong, OpenSCAD can access the mesh just fine from a built-in
and that specifically was the proposal in the OP.
Of course I was referring to the explicit request for bend()
functionality as available to the end user, I am sure you understood
that. It is certainly not "wrong" that those capabilities are missing,
otherwise they would not be requested as the TS did.
The restriction is only that this feature can not be implemented
as a library at this point.
Indeed, it was the case 5 years ago and today.
But I guess the point was to get AngelCAD into the discussion
as it was not mentioned in this thread yet.
You probably guess that, but MY point was that bending/morphing is
possible if you want to do it. AngelCAD came to be after I started using
OpenSCAD in 2015 and suggested various improvements then, but it was met
with too much "cannot do" so I solved it in a different way.
Carsten Arnholm
On Sat, Sep 14, 2019, at 4:57 PM, Torsten Paul wrote:
As for the transformations, those may need support from
the core, specifically to automatically subdivide the
mesh. Especially for bending there's a longer discussion
on github already. I suspect that's something a number
of people would like to see.
https://github.com/openscad/openscad/issues/815
If you want core support for arbitrary non-affine transformations such as "bend", then in general it is more complicated than just the need to automatically subdivide the mesh. Non-affine transformations can also cause self-intersections, and can cause triangles to collapse. That damage needs to be repaired before you can feed the output into CGAL operations such as intersection and union.
In the case of Bend, you get self-intersection just by bending a pipe past 180°.
I was one of the people discussing how to do non-affine, plastic deformations in OpenSCAD back in 2014. To do this in mesh space, we discussed automatic subdivision in regions where space expands, and remeshing to a valid mesh afterwards. It seemed way too complicated to actually implement (for me, at least). Since I needed this feature for my own projects, I implemented it outside of OpenSCAD by representing shapes using signed distance fields (SDF). Using that representation, you can represent curved shapes exactly. Plastic deformations like twist and bend are easy to implement, and they output an exact representation, so there is no loss of information or degradation of the model if you apply a sequence of non-affine transformations. Then, as a final step for generating an STL file, you convert the signed distance field into a mesh using available open source software.
There was discussion, some time around 2014, about adding native support for working with SDF representation to OpenSCAD, but it's a big and radical change, and seems unlikely to happen.