Extending OpenSCAD from assembler to C or Perlish language and adding standard library
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/