Yes, for a triangular base pyramid you would want $fn a multiple of 3 I
suppose but would exact dimensions matter for such a shape when $fn is high
enough to make it smooth? I find, in generally, that only dimensions
parallel to the axes matter in my designs. They are however function over
form, with no artistic element.

On Fri, 26 Apr 2019 at 13:13, adrianv avm4@cornell.edu wrote:

nophead wrote

That's only if the pyramid is a tetrahedron with an equilateral base.  I had
suggested a generic pyramid, with arbitrary polygonal base (assume convex)
and abitrary apex position.  It's tough to even figure out where the sphere
centers should be if they are perfect spheres.

I printed models with $fn=8 and had print failures because the base of my
model wasn't coplanar due to the error in sphere dimensions.  I do note
that the base is parallel to the coordinate plane.

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

Yes the built in sphere is missing the poles, so the base would be lifted a
bit. I would never notice because I never use a full sphere at the base
because it starts too horizontal. I use inverted rotate_extruded teardrops
when I need a rounded base, so that starts at 45 degrees. And I never use
such low values of $fn. For example this handle, which is printed flat side
down.

[image: handle.png]

Not perfectly rounded but comfortable enough to hold and easy to print. It
previews in less than a second and renders in 3 seconds. I had to avoid
implicit union inside the hull to get that speed.

On Fri, 26 Apr 2019 at 19:49, adrianv avm4@cornell.edu wrote:

On 25.04.2019 21:44, TLC123 wrote:

Good rant. I agree the efforts in developing user-space solutions in
OpenSCAD are daunting to all but a few, partly because of the
declarative language, where the order of things don't matter as in other
languages and where you cannot reassign variables. etc.

Also, the inherent slowness of CGAL seems to drive some of the advanced
efforts in user space, but the limitations of the language makes it
quite difficult to make progress in my opinion. These efforts are
commendable, but they seem to mainly try to work around limitations of
CGAL speed instead of using its strengths. Again, in my subjective opinion.

So I think that if the core is fast and the language available to the
user is rich, it means more features can be developed in user space. A
fundamental requirement is that that the core functionality runs fast
enough for non-trivial problems.

The last couple of years I have been developing an independent tool that
addresses these issues. The tool is called AngelCAD and it has recently
been released as open source, more information & downloads at
https://arnholm.github.io/angelcad-docs/

The philosophy in AngelCAD is to use a fast boolean engine (Carve)
combined with a rich scripting language (AngelScript), so perhaps it
will enable development of user space libraries

An example of rounding with AngelCAD (runs < 0.5 sec with rounding).
https://gist.github.com/arnholm/248d9a14e92b05ab8942d5f9a6611851

Carsten Arnholm

Nice, but I have no problem with the declarative functional style of
OpenSCAD  . I prefer that type of language when describing objects rather
than procedural. The huge problem is the speed and memory requirements of
CGAL. Can it be replaced by Carve in OpenSCAD?

On Fri, 26 Apr 2019 at 20:46, Carsten Arnholm arnholm@arnholm.org wrote:

On 2019-04-26 23:59, nop head wrote:

What is the reason for this preference other than having invested time
and effort into it? Is there in your opinion something fundamental that
makes it easier to describe objects this way? I can't see what it would
be. Maybe some examples can illustrate.

The features of AngelCAD illustrates that the answer is that it probably
can. Using Carve in AngelCAD has a much smaller footprint in memory and
time spent, but I can't know for sure whether this is only because of
CGAL vs. Carve, or whether it reflects how the two libraries are being
used in the host applications (point to note: Carve is used only in
xcsg, AngelCAD is the scripting front end visible to users).

Carsten Arnholm

I find a declarative language more natural for describing static geometry.
Variables do not need to change because it is a description, not an
algorithm. It's like a make file or an HTML page, both are declarative
languages. Yes you can embed script in HTML but that is only necessary to
make it interactive or to read a database. A static page of text and
graphics is just a description of a tree of objects, like OpenSCAD.

Having variables that don't change makes code more readable and less error
prone. That is why moving everything to const in C++ is encouraged. And is
more like maths, which is appropriate for describing geometry. a = a + 1 is
nonsense in maths.

I don't struggle to code anything I need in OpenSCAD but avoiding CGAL as
much as possible is tedious and makes code less readable. If it was about
1000 times faster and used 1000 times less memory I could code directly in
3D rather than decomposing everything into unions of extruded 2D. And
rounding in 3D with minkowski would be practical.

On Sat, 27 Apr 2019 at 06:39, arnholm@arnholm.org wrote:

BTW, I don't think your pyramid has the correct dimensions, as Adrianv
eluded to, it is not trivial to place the spheres for a non rectangular or
irregular shape. However, I don't see why exact dimensions would be
important to such shapes.

On Sat, 27 Apr 2019 at 09:13, nop head nop.head@gmail.com wrote:

On 27.04.2019 10:13, nop head wrote:

These are personal preferences, which is fine. In OpenSCAD users are
describing series of operations using parameters, i.e. describing what I
consider algorithms to generate models, they don't provide explicit
descriptions of the finished product. But this is semantics and not a
big deal in my book.

In some cases you have to use convoluted recursive procedures to build
datastructures in OpenSCAD, those are algorithms as well. Nothing wrong
with recursion, you can use it in AngelCAD to, but there it isn't the
only option on the table.

That is not really what constness in C++ (or AngelCAD) is about. What
makes readable code is debatable. For example, if you do this in OpenSCAD

radius = 1000;
radius = 500;
sphere(radius);

Is it supposed to be legal, and if so what is the correct result? Is the
result consistent with the statement that variables don't change?

If you do instead

radius = 500;
radius = 1000;
sphere(radius);

you get a different result, but considering the idea that the order of
things are not supposed to matter in the OpenSCAD language, the result
seems counterintuitive to me.

In this trivial case it is easy to spot that something is odd, but if it
is part of a larger section of code it is indeed error prone. With error
prone I mean it doesn't match the user expectation, given the language
rules of supposed constness and independence of sequence.

In summary, whatever the rules and syntax of a language, there are
plenty options to write unreadable and confusing code in any language
and OpenSCAD is no exception in this regard.

This agrees with my first point earlier. Because of the slowness of CGAL
and/or how it is applied, you end up working around the core feature of
OpenSCAD.

Carsten Arnholm