Extending OpenSCAD from assembler to C or Perlish language and adding standard library

classic Classic list List threaded Threaded
110 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Extending OpenSCAD from assembler to C or Perlish language and adding standard library

sampo-openscad19
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:

1. There should be more convenience geometries supported natively rather than
   through libraries or well known programming practises.

2. 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).

3. 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

* 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

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
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/

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

tp3
In reply to this post by sampo-openscad19
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, [hidden email] 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.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

cacb
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

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

tp3
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.


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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
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/

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

tp3
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.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

MichaelAtOz
Administrator
In reply to this post by sampo-openscad19
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
>
> * 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


---
This email has been checked for viruses by AVG.
https://www.avg.com


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

cacb
In reply to this post by tp3
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

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

doug.moen
In reply to this post by tp3
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.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

tp3
In reply to this post by MichaelAtOz
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.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

JordanBrown
In reply to this post by sampo-openscad19
On 9/14/2019 7:29 AM, [hidden email] wrote:
1. 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.

2. 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.


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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
This post was updated on .
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.

Developer time is always scare and it should be used for things that benefit large numbers of users.

...R
PS ... I tried to make some of the quoted text BOLD, but that does not seem to work



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

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Troberg
In reply to this post by sampo-openscad19
sampo-openscad19 wrote
> 3. 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

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
>
> * 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/

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

doug.moen
In reply to this post by sampo-openscad19
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, [hidden email] 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

nophead
> 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 <[hidden email]> 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, [hidden email] 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

JordanBrown
In reply to this post by Robin2
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. :-)


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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
In reply to this post by doug.moen
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/

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

tp3
In reply to this post by Troberg
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.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

lar3ry
In reply to this post by Robin2
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/

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