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.
On 15.09.19 05:20, OzAtMichael wrote:
- 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.
It's a bit tricky as a naive implementation would at least
cause issues with the camera location (same as when using
a huge cube manually), but it should be doable.
There's a partially working but unfortunately abandoned
implementation at
https://github.com/openscad/openscad/pull/1424
ciao,
Torsten.
On 9/14/2019 7:29 AM, sampo-openscad19@zxid.org wrote:
- There should be more convenience geometries supported natively rather than
through libraries or well known programming practises.
No, there's really no reason. It would be much better to have
well-known libraries distributed with the program. Primitives should be
added only for those things that have to be primitive.
There's a decent argument that even translate, rotate, scale, cylinder,
cube, and the ilk should be library modules on top of multmatrix and
linear_extrude.
- 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).
Strongly disagree. Readability is critical. Terseness is bad.
- Make center=true the default (or settable as document global default)
If we were starting from nothing, maybe. But now it would be too
disruptive and confusing.
- Make the ca. 10 export options appear directly in the File menu so that cumbersome
access to submenu is not needed
Shrug. I almost never have to get into the menus, so there must not be
too much there that I need.
-
Make Ctrl-+ work as zoom-in (in addition to C-])
-
Make Ctrl-- (minus) work as zoom-out (in addition to C-{)
I find the mouse wheel to be a very natural zoom control.
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)
Sound like decent library fodder, though I have to wonder how much use
they would really get.
-
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
These are obscure enough that they should not use up single-letter
module names - and especially not as primitives, where they would
collide with every user's usage.
- In general add to cube(), cyl(), spehere(), and hull() a wall=X parameter,
which, when supplied, will produce a hollow version of the object
Perhaps, though it would be easy enough (except for hull) to create
library modules hollow_cube() et al.
- 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.
It's pretty easy to do a set of linked cylinders, and that should
perhaps be a library module. I haven't thought about making it into a tube.
A library function to produce a list of Bezier points would be good, and
then you could use that as input to your linked-cylinder module. (And I
have!)
- sqtube_path()
I thought about this a bit once and the rotation of the square defeated
me. I don't remember the details, but it wasn't obvious how the square
would be rotated as you connected one point to the next.
- hull_path()
What does that mean?
- bend(), stretch() and shear() transformations
I don't know enough math to discuss bending.
What is stretching that isn't handled by scale( )?
Shear isn't too hard to put on top of multmatrix, and I don't know (and
haven't thought too much) if it's possible to come up with a general
shear that's less complex than multmatrix. There's a lot of different
shear combinations.
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
That would be cool, but is clearly just (difficult) library work.
- set of screws, bolts, and nuts
- metric (and imperial?)
- different options for heads (sink, ball, etc.)
There are screw/bolt libraries. It's mostly a matter of making them
easy to get.
- standard tools for cutting or mitering
What does this mean?
- 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.
I think you can do this with linear_extrude today (and hence you could
make your own module), but it seems reasonable.
JordanBrown wrote
Sound like decent library fodder, though I have to wonder
how much use
they would really get
.
sampo-openscad19 wrote
- There should be a standard library of commonly needed objects, like
parametrized ergonometric human model or (metric) screws and nuts.
Would be nice as external libraries, but not the core language.
sampo-openscad19 wrote
- Make center=true the default (or settable as document global default)
Strongly disagree. It's almost never useful with center=true for anything
but spheres. Would break backwards compatibility.
sampo-openscad19 wrote
- Document conspiciously that PI constant (3.14) is supported, perhaps
near description
of speacial variables like $fn
Need quite a few more decimals than that to be useful.
sampo-openscad19 wrote
-
translate() -> T(). As translate is the most common expression,
abbreviating it would be of capital importance. -
rotate() -> rot()
-
difference() -> diff()
-
cylinder() -> cyl()
Disagree. Keep the language as close to spoken language as possible. It's
easy to make yout own T() if you want (I almost do, I have my xtran(),
ytran() and ztran() to make it clearer when I only move in one direction,
and corresponding xrot() et cetera). Would break backwards compatibility.
sampo-openscad19 wrote
- Make the ca. 10 export options appear directly in the File menu so that
cumbersome
access to submenu is not needed
Disagree. That's not how it's done in other programs, and would give menu
clutter.
sampo-openscad19 wrote
- Add keyboard shortcut C-space for menu View -> Reset view
Not something I'd use, but I can see that it's useful. Agree.
sampo-openscad19 wrote
- 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
- This is by far the most frequent and important export so it deserves
Agree that export should be able to be done in batch. Disagree that STL is
the most important export, at least not for me. I don't 3D-print, I have a
laser cutter, so SVG is the format for me.
sampo-openscad19 wrote
- 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
Wouldn't use the keybord shortcut, I seldom remember more than the most
common. I'm pretty sure there is a command line option for it, I'm pretty
sure that I batch it.
sampo-openscad19 wrote
-
Make Ctrl-+ work as zoom-in (in addition to C-])
-
Make Ctrl-- (minus) work as zoom-out (in addition to C-{)
Wouldn't use, scroll wheel is more convenient. Don't see any harm in it,
though.
sampo-openscad19 wrote
-
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
I already have made versions of those. Shouldn't be included in main
language, but would be suitable for an external lib.
sampo-openscad19 wrote
- In general add to cube(), cyl(), spehere(), and hull() a wall=X
parameter,
which, when supplied, will produce a hollow version of the object
Shouldn't be included in main language, but would be suitable for an
external lib.
sampo-openscad19 wrote
- 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)
Shouldn't be included in main language, but would be suitable for an
external lib.
sampo-openscad19 wrote
-
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
Yes, these would be useful, though I'd probably make it a path_extrude().
sampo-openscad19 wrote
-
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
Shouldn't be included in main language, but would be suitable for an
external lib.
sampo-openscad19 wrote
-
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.
Shouldn't be included in main language, but would be suitable for an
external lib.
sampo-openscad19 wrote
- 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)
Would be nice, sometimes it can be hard to see when you have complex models.
I usually have to revert to using intersection() to remove part of the
object for view.
sampo-openscad19 wrote
- 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.
Shouldn't be included in main language, but would be suitable for an
external lib.
sampo-openscad19 wrote
- Coloring with patterns like wood grain (to show the intended orientation
of the grain,
and that the object is to be made of wood)
Textures is a bit of overkill, imho, but I would like to be able to render
in color.
--
Sent from: http://forum.openscad.org/
As some people know, I created my own OpenSCAD-like language, Curv. Some of the changes I made align with what Sampo is asking for, so I'll comment on those specific issues, based on several years experience using Curv.
On Sat, Sep 14, 2019, at 10:29 AM, sampo-openscad19@zxid.org wrote:
- Make center=true the default (or settable as document global default)
Curv works this way: all primitive shapes are centred on the origin. It has proven to be very convenient. My entire shape library is designed around the idea that primitives are centred, so that everything composes nicely with a minimum of extra translations.
Backward compatibility is paramount in OpenSCAD. For people who want centred primitives, there should be a user-provided library that redefines the primitives to be centred.
OpenSCAD should add the flexibility to override built-in modules with new modules of the same name. You should be able to define a module called cube, and you should be able to reference the builtin module cube while defining the new version of cube.
- translate() -> T(). As translate is the most common expression,
abbreviating it would be of capital importance.
My abbreviation for translate is move. This should be done in a library, because it's a personal preference. Ditto for many of Sampo's other suggestions.
- Add keyboard shortcut C-space for menu View -> Reset view
C-space is globally reserved in some desktop environments. MacOS uses Cmd-Space for Spotlight search. Some Linux and Windows systems use Ctrl-Space to switch input editors.
How about C-Home? Or maybe a configuration file for user defined key bindings?
- bend() transformation
Curv has two non-affine transformations, bend and twist, that I use a lot. Can't live without them. These should be implemented in OpenSCAD in a user-supplied library.
OpenSCAD should provide the ability to access the mesh geometry of a shape from user code. Then bend() could be implemented using the approach that Carsten described, in his AngelCAD implementation.
Whenever this feature request is discussed, it is always dismissed by claiming that it is incompatible with preview. That's not true. OpenSCAD has a number of built-in modules that access the mesh geometry at preview time: render(), resize(), minkowski(), hull(). Yes, it's true that these operations can slow down preview. With complex models, render() can also speed up preview, or fix rendering problems in preview. If I can call render() from a user-defined module, then why is it so objectionable to allow me to call a variant of render() that returns the mesh as a list?
- 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.
The cylinder() primitive is the standard way to construct pyramids in OpenSCAD. Try this:
cylinder(h=10, r1=10, r2=0, $fn=4);
No doubt there are already libraries in existence that provide this same capability using a pyramid module.
- 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)
You can do this interactively using the previewer. Define a slider for moving the boundary of the big cube and enable "automatic preview". There are lots of interactive visualization tools you can build once you have a previewer. They don't all need to be built in.
My complaint against the OpenSCAD previewer is that automatic preview is laggy. Curv has a much more responsive previewer, and it makes a big difference in terms of quality of experience, so I think this issue should be considered.
Curv compiles programs with previewer annotations into a specialized form that supports responsive animation (60 FPS) when you move a slider. The tradeoff is restrictions on what programs can be compiled in this way. Over time, I'm progressively eliminating these restrictions. So I prioritized responsiveness over generality.
- Coloring with patterns like wood grain (to show the intended
orientation of the grain,
and that the object is to be made of wood)
Curv supports full colour models and full colour 3D printing. My Prusa doesn't support this, but there online 3D printing service providers that support this, and I really enjoy being able to make full colour prints. My new favourite colour 3D printing tech is the HP 3D Jet Fusion 500/300. It prints full colour nylon, which is tough and strong, more durable and somewhat brighter colours than "full colour sandstone" from a Zcorp printer, and a lot cheaper than Shapeway's Stratasys J750.
In Curv, you can attach a colour function to a shape. A colour function maps [x,y,z] coordinates to colour values. So every "voxel" in a shape can have a different colour. This was easy to implement, and it's really cool. "Wood grain" might sound out-of-scope for OpenSCAD, but once you support 3D colour functions, it's quite possible. One of my users surprised me by demoing a wood grain model in Curv: I hadn't previously considered this to be something I can do. But now I'm a convert. I think this would be a popular feature for OpenSCAD to adopt.
The general theme of my recommendations is to give users lots of power to define things in code, rather than hard coding a lot of features in C++. I think this is already a reason why OpenSCAD is attractive, so we should just keep building on this core strength.
Doug Moen.
You should be able to define a module called cube, and you should be
able to reference the builtin module cube while defining the new version
of cube.
It doesn't make for readable and reusable code if everybody has their own
dialect of OpenSCAD where cube does something different.
If I can call render() from a user-defined module, then why is it so
objectionable to allow me to call a variant of render() that returns the
mesh as a list?
I think because a list is an expression and all expressions are
evaluated in OpenSCAD before any geometry is created.
On Mon, 16 Sep 2019 at 16:22, Doug Moen doug@moens.org wrote:
As some people know, I created my own OpenSCAD-like language, Curv. Some
of the changes I made align with what Sampo is asking for, so I'll comment
on those specific issues, based on several years experience using Curv.
On Sat, Sep 14, 2019, at 10:29 AM, sampo-openscad19@zxid.org wrote:
- Make center=true the default (or settable as document global default)
Curv works this way: all primitive shapes are centred on the origin. It
has proven to be very convenient. My entire shape library is designed
around the idea that primitives are centred, so that everything composes
nicely with a minimum of extra translations.
Backward compatibility is paramount in OpenSCAD. For people who want
centred primitives, there should be a user-provided library that redefines
the primitives to be centred.
OpenSCAD should add the flexibility to override built-in modules with new
modules of the same name. You should be able to define a module called
cube, and you should be able to reference the builtin module cube while
defining the new version of cube.
- translate() -> T(). As translate is the most common expression,
abbreviating it would be of capital importance.
My abbreviation for translate is move. This should be done in a library,
because it's a personal preference. Ditto for many of Sampo's other
suggestions.
- Add keyboard shortcut C-space for menu View -> Reset view
C-space is globally reserved in some desktop environments. MacOS uses
Cmd-Space for Spotlight search. Some Linux and Windows systems use
Ctrl-Space to switch input editors.
How about C-Home? Or maybe a configuration file for user defined key
bindings?
- bend() transformation
Curv has two non-affine transformations, bend and twist, that I use a
lot. Can't live without them. These should be implemented in OpenSCAD in a
user-supplied library.
OpenSCAD should provide the ability to access the mesh geometry of a shape
from user code. Then bend() could be implemented using the approach that
Carsten described, in his AngelCAD implementation.
Whenever this feature request is discussed, it is always dismissed by
claiming that it is incompatible with preview. That's not true. OpenSCAD
has a number of built-in modules that access the mesh geometry at preview
time: render(), resize(), minkowski(), hull(). Yes, it's true that these
operations can slow down preview. With complex models, render() can also
speed up preview, or fix rendering problems in preview. If I can call
render() from a user-defined module, then why is it so objectionable to
allow me to call a variant of render() that returns the mesh as a list?
- 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.
The cylinder() primitive is the standard way to construct pyramids in
OpenSCAD. Try this:
cylinder(h=10, r1=10, r2=0, $fn=4);
No doubt there are already libraries in existence that provide this same
capability using a pyramid module.
- 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)
You can do this interactively using the previewer. Define a slider for
moving the boundary of the big cube and enable "automatic preview". There
are lots of interactive visualization tools you can build once you have a
previewer. They don't all need to be built in.
My complaint against the OpenSCAD previewer is that automatic preview is
laggy. Curv has a much more responsive previewer, and it makes a big
difference in terms of quality of experience, so I think this issue should
be considered.
Curv compiles programs with previewer annotations into a specialized form
that supports responsive animation (60 FPS) when you move a slider. The
tradeoff is restrictions on what programs can be compiled in this way. Over
time, I'm progressively eliminating these restrictions. So I prioritized
responsiveness over generality.
- Coloring with patterns like wood grain (to show the intended
orientation of the grain,
and that the object is to be made of wood)
Curv supports full colour models and full colour 3D printing. My Prusa
doesn't support this, but there online 3D printing service providers that
support this, and I really enjoy being able to make full colour prints. My
new favourite colour 3D printing tech is the HP 3D Jet Fusion 500/300. It
prints full colour nylon, which is tough and strong, more durable and
somewhat brighter colours than "full colour sandstone" from a Zcorp
printer, and a lot cheaper than Shapeway's Stratasys J750.
In Curv, you can attach a colour function to a shape. A colour function
maps [x,y,z] coordinates to colour values. So every "voxel" in a shape can
have a different colour. This was easy to implement, and it's really cool.
"Wood grain" might sound out-of-scope for OpenSCAD, but once you support 3D
colour functions, it's quite possible. One of my users surprised me by
demoing a wood grain model in Curv: I hadn't previously considered this to
be something I can do. But now I'm a convert. I think this would be a
popular feature for OpenSCAD to adopt.
The general theme of my recommendations is to give users lots of power to
define things in code, rather than hard coding a lot of features in C++. I
think this is already a reason why OpenSCAD is attractive, so we should
just keep building on this core strength.
Doug Moen.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 9/16/2019 12:56 AM, Robin2 wrote:
JordanBrown wrote
Sound like decent library fodder, though I have to wonder how much use
they would really get
That should be the test for every change.
Yes, though the standards are different for different "levels".
Primitive - should probably be only those things that must be
primitive, or that have significant performance gains from being primitive.
"Standard" library distributed with program - common usage.
"Extra" library distributed with program - some specialty stuff, but
might be used by only 10% of users. Or maybe even fewer.
Or maybe there are a few "extra" libraries for specialties - e.g.,
construction materials, fasteners, et cetera.
And then there's everything else, that's not distributed with the
program - yeah, whatever. :-)
doug.moen wrote
OpenSCAD should add ....
OpenSCAD should provide ....
Why?
How many users, and what type of user, would benefit?
...R
--
Sent from: http://forum.openscad.org/
On 16.09.19 11:54, Troberg wrote:
sampo-openscad19 wrote
- Document conspiciously that PI constant (3.14)> > supported, perhaps near description of speacial
variables like $fn
Need quite a few more decimals than that to be useful.
Just to clarify, the built-in PI is not just 3.14,
it's using the platform C/C++ definition M_PI which
should be double precision.
ciao,
Torsten.
Robin2 wrote
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.
I agree wholeheartedly. I have no trouble remembering shorthand substitutes
for commonly used keywords, but ONLY if I defined them myself. As you say,
single character shortcuts are not only bad for searching, but also for
parsing, should one want to generate a translation program that will take an
OpenSCAD file with shortcuts and pretty-print the full OpenSCAD code. I love
the idea of xtran(n), ytran(n), ztran(n), and so on.
This discussion has been a real eye-opener for me. I will definitely be
generating a library file that includes many of the ideas presented here...
shortcuts, tubes, hollow cubes, and so on, and will attempt to write a
program that will translate all the shortcuts at the very least, back to
native OpenSCAD.
--
Sent from: http://forum.openscad.org/