Yes you can't query the geometry in OpenSCAD but I never need to do that
because I specify the geometry precisely with maths.

I don't make anything with hand tools, so I don't need dimensioned
drawings. I make my designs so that they fit around parts they need to
mount or mate with. I don't care what the final dimensions are, they are
often far from round numbers due to the build up of parameters and
clearances and radii. If I want to sanity check something, I examine the
STL in NetFabb before printing it.

Before OpenSCAD I used CoCreate but since switching to OpenSCAD I would
never consider a GUI based CAD system because I a computer programmer, not
a mechanical design engineer. I can't even sketch anything in 3D and have
difficulty imagining 3D shapes. I start with a mental model of how the non
printed parts need to be arranged and design the plastic around them.

On Wed, 2 Oct 2019 at 11:35, Robin2 robin@nbleopard.com wrote:

On 2019-10-02 12:42, Robin2 wrote:

It is a fair assessment.

OpenSCAD and similar programs are based on the Constructive Solid
Geometry method (
https://en.wikipedia.org/wiki/Constructive_solid_geometry ), which is
kind of an implicit way of defining a model, which makes it harder to
refer to details in the model. Another thing is that the OpenSCAD
language explicitly does not allow any model queries, this is a design
choice. Another difference is that the OpenSCAD internal model
representation is mesh based using CGAL, which is fundamentally
different from the internal model representation in FreeCAD.

In FreeCAD, the internal representation is based on OpenCascade, which
is a boundary representation model (BREP), and not a mesh model. The
OpenCascade model is much more complex and more equivalent to
traditional CAD programs. OpenSCAD (and AngelCAD) are not directly
comparable because of the mesh representation.

Whether you can "ask questions" or not is related to the internal
representation and difficulties of referring to parts of the model, but
it is not the whole story. It is also a question of design philosophy.

Carsten Arnholm

There are two use cases I can think of for being able to query objects for
information. One is when you import external objects and then wish to add
things to them. The second is to make implementing generic library code.
In the first instance, I spend a LOT of time rendering objects with shadow
cubes in various positions to determine the actual dimensions of the
imported objects. This work then has to be repeated whenever the original
object is updated to a new version. Tinkercad appears to be particularly
bad for putting objects in different positions every time...
The second instance can be worked around by adding parameters but it is
essentially redundant information. For example, a module to put a hole
through a cube could have parameters to specify the size and the
orientation of the cube, but this is essentially redundant and prone to
failure. Any time the same data needs to be specified twice, you are making
updates to the code more difficult to get right.

On Wed, 2 Oct 2019, 09:08 fred via Discuss, discuss@lists.openscad.org
wrote:

I never specify the same thing twice. If I need a position twice I usually
make it a module that positions its children and call it multiple times.

On Wed, 2 Oct 2019 at 14:27, A. Craig West acraigwest@gmail.com wrote:

who has no experience of programming and does not know how to conceive a
programmed solution for a problem.

Yes I would think so, but it is a CAD tool for programmers, not the general
public. Mechanical engineers I know would use a conventional CAD program
and would have no idea how to write programs or use OpenSCAD and even a
good friend that is an experienced programmer prefers conventional CAD and
thinks I am mad to use OpenSCAD.

On Wed, 2 Oct 2019 at 14:29, Robin2 robin@nbleopard.com wrote:

cacb wrote

Thanks, and also to @nophead.

I'm trying to figure out how to explain the differences to a novice without
him or her needing to understand the technical foundations so that they can
decide which program is best for what they want to make. A novice will have
to take the trouble to learn no matter what program they decide to use - so
they should not waste time learning one that cannot meet their needs or
waste time learning a complex program if a simpler one would be sufficient.

There are many instructional videos on Youtube (for example making a fidget
spinner) that demonstrate the different programs. But the reality is that
the person making the video already knows how to use the program so the
video does not give a fair impression of how easy it would be for the
novice.

If you know the basics of programming then Openscad's learning curve is a
lot more gentle. But, at least to start with, I suspect it is just as
impenetrable as the other programs for someone who has no experience of
programming and does not know how to conceive a programmed solution for a
problem.

...R

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

Besides his or her preference for a programmer's approach in modelling, the
OpenSCAD user should be fairly comfortable with geometry and math.

A quarta, 2/10/2019, 14:36, nop head nop.head@gmail.com escreveu:

nophead wrote

That seems to me a very narrow marketing concept.

I agree that professional engineers are not the target market but shouldn't
the Openscad community be looking for ways to get as many hobbyists as
possible to use Openscad - even if they are not programmers?

...R

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

There are ways to keep track of dimensions in openscad using parameters. If
you just type cube([10,2,12]); that doesn't produce a record of what those
dimensions where. If they are important or used multiple places it can
often be a good idea to start the script by stating parameters.

cube_l = 10;
cube_w = 2;
cube_h =12;

cube([10,2,12]);

Now we know the dimension of the object if we need to reference it later
like perhaps to put a mitered piece on it.

Another neat trick is to put a hashtag in front of an object to make it
transparent, this way you know what object in the design that line is
referencing. So if you aren't sure if a cylinder is a cut out for a hole or
part of a different part of an assembly you can pick it out of the design.
Be aware this only applies to the f5 preview and has no effect on the final
render. You can also have your finished design and use a #cube(); function
to find the bounding box by iterating the size of the cube, your precision
is limited but it can be useful to ball park the size of the stock you
would need to make something in a subtractive manufacturing process.

Last thing i'll say is that it can be useful to take your design and
difference it from a cube which you manipulate to form different cutouts.
Obviously only relevant if you have internal features, but can be very
helpful.

Openscad is powerful when you can express the final shape in terms of a
mathmatical relationship between objects, or when some really smart person
made a package which does exactly what you want and you can scale it to
your application.

On Wed, Oct 2, 2019 at 5:35 AM Robin2 robin@nbleopard.com wrote:

--
Matt Maggio
Senior Research Technologist
Resuscitation Institute (Rm. 1.380)
Department of Medicine
Rosalind Franklin University of Medicine and Science
3333, Green Bay Rd, North Chicago, IL - 60064.
Office: 224-570-7954
Cell: 815-703-2879
"Take chances, make mistakes, and get messy!!" - Mrs. Frizzle, PhD

Nothing is for sale here.

shouldn't the Openscad community be looking for ways to get as many
hobbyists as possible to use Openscad - even if they are not programmers?

I don't know. I would never recommend it to anyone that isn't a programmer,
particularly now that there are good free CAD tools, both open and closed
source. Writing software is a very slow process and so is designing objects
with OpenSCAD. When I see what James Bruton knocks up with Fusion360 I
realise it is much more productive that coding in OpenSCAD.

On Wed, 2 Oct 2019 at 17:50, Matt Maggio mattmaggio19@gmail.com wrote:

nophead wrote

That does not mean that the product should not be marketed - that is, if you
want to widen the user base.

I don't know who James is but I suspect he is very familiar with Fusion360.

I'm thinking of the novice who knows none of the CAD programs and may only
want to build one or two models in a year. For that sort of user a system
that requires very little learning will be very attractive. I think Openscad
can be that system.

...R

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

I like math. I like geometry, algebra, trigonometry and even one semester of calculus, but don't ask me to remember any of the latter!
Trying to engage our makerspace members in OpenSCAD hasn't been fruitless, but as soon as numbers come into play, all bets are off. So far, most of them are full GUI users, ala Tinkercad or rarely Onshape, so having to type (no typing skills either) in words and do math and create geometry scares away most.
Recently a new member, with a passing interest in programming became aware of both OpenSCAD and Solvespace. The former you know, the latter is GUI, but parametric and constrained. Useful for a variety of things and a handy tool for the toolbox.
The new member, let's call him John (because it's his name) embraced OpenSCAD with an enthusiasm I've not seen before. He used the same method I enjoy. Look at someone else's work, try something, if it doesn't work, try something else and of course, trouble shoot why the first one didn't cut it.
Every person takes a different approach to a modeling program, and OpenSCAD certainly fits for many people.
The price is hard to beat.

On Wednesday, October 2, 2019, 3:25:11 PM EDT, Robin2 <robin@nbleopard.com> wrote:  

nophead wrote

That does not mean that the product should not be marketed - that is, if you
want to widen the user base.

I don't know who James is but I suspect he is very familiar with Fusion360.

I'm thinking of the novice who knows none of the CAD programs and may only
want to build one or two models in a year. For that sort of user a system
that requires very little learning will be very attractive. I think Openscad
can be that system.

...R

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

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

OpenSCAD mailing list wrote

Same as its competitors - Solvespace and Freecad.

So the competition must be fought with something other than price - such as
an easier learning curve?

...R

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

OpenSCAD mailing list wrote

Well, it's not strictly necessary, true, but in some cases, it would be very
handy.

Examples:

When things move around a lot. Think of a robot arm, with several bend
points. Sure, build it part by part and be careful, and you can do it, but
occasionally (for example if you do an anim), you might want to know where
the claw is without having to to do all the math.

Say that you are doing a an axle, with bunches of nuts and washers, passing
through several  other bits. Sure, the math is easy, but if components are
designed as modules, I need to check out how thick a nut or a washer is,
instead of just "stack them".

Making rounded/chamfered corners on parts. If you could just query the item,
it would be pretty simple to just get the needed dimensions and procedurally
add the roundings/chamfers.

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

For a complex assembly like a robot arm I would have modules to position
each segment onto the last one. So there would be say
shoulder_upper_arm_position(), upper_arm_forearm_position() and
forearm_wrist_position().

In the arm assembly the hand would be a child of the forearm, placed with
forearm_wrist_position() and the forearm would be a child of the upper arm,
positioned with  upper_arm_forearm_position (), etc.

If I want to say put a ring on a finger it would simply be a matter of
calling the right sequence of positioning modules, no extra maths at all.
something like:

left_shoulder_position()  shoulder_upper_arm_position ()
upper_arm_forearm_position() forearm_wrist_position()
wrist_ring_finger_position()  ...  ring();

The joint positions might be parameters to each positioning module, or
perhaps $variables.

The position of the ring would be a long chain of transformations but that
is hidden. If I wanted it in X,Y,Z coordinates I would put the maths from
the positioning modules into into functions with the same name. Then the
module version would simply be

module  shoulder_upper_arm_position ()
multmatrix(shoulder_upper_arm_position() ) children();

Then I could call the function versions and multiply the matrices together
to get a transformation matrix the goes from the origin of the robot to the
ring. Mulitpling that by [0, 0, 0, 1] gives the coordinate of the ring.

For stacking washer, my washer and nut modules position their children on
top of themselves. So nut(..) washer(..) nut(..) washer(..)  screw(..)
would build a washer kebab.

On Thu, 3 Oct 2019 at 07:34, Troberg troberg.anders@gmail.com wrote:

I express all the properties I need for my objects with functions and
modules. Each parametric object is represented by a list with a set of
accessor functions, so nothing is specified twice and I don't need to query
the geometry. All the important features of an object are built with its
accessor functions. It is a bit clunky as there is a lot of boiler plate to
write but it is very simple code in a simple language, so should be easily
understood.

Syntactic sugar would be object.property instead of
object_property(object). Function literals will allow functions to be
embedded in the property list, so objects can be polymorphic.

On Thu, 3 Oct 2019 at 11:56, Troberg troberg.anders@gmail.com wrote:

What OpenSCAD is missing that traditional cad programs have is the
ability to "snap". two pieces together.

Sure you can keep track of where you put the holes, etc., but
something like intersection() creates new surfaces that may be
difficult to find the edges and surface tangents of, may require
complex trigonometry and/or geometry to calculate...

On Thu, Oct 3, 2019 at 6:56 AM Troberg troberg.anders@gmail.com wrote:

I just don't come across that in practice. If an object has an important
dimension, that is usually input parameter of the object, so even if it is
created with an intersection, or a difference, the part that does the
removal has to be positioned so that it gives the required important
dimension. That may need some trig but it is never more than I learned at
high school 40 years ago and can still remember, so I wouldn't call it
complex. Just a bit of triq and some circle intersection equations that I
Google for.

Why would you do some arbitrary intersection and then try to find the
resulting dimensions?

On Thu, 3 Oct 2019 at 12:21, Steven Dick kg4ydw@gmail.com wrote:

It occurs a lot more often when you are trying to work with imported shapes

On Thu, 3 Oct 2019, 07:34 nop head, nop.head@gmail.com wrote:

In my experience, the answer to your question is that you want to do some
kind of rounding or edge treatment that finishes before the heat death of
the universe---or maybe just part of the model needs to be rounded.  So
minkowski() is out. I made a model based on a sine wave shape.  The model
wasn't designed around some spec that required certain dimensions for
everything, so some things were arbitrary, but I still wanted to round off
those arbitrary ends.  I'm not saying it can't be done, but you're going to
need calculus and you might potentially need to solve a transcendental
equation, which means you need to implement an iterative solver (e.g
Newton's method using tail recursion) unless you want to just hard code
values.

Just knowing the location of the intersection may not be enough to solve
problems like this in general.  At least in principle, when I 3d print
something every edge should be rounded unless a specific functional reason
requires a sharp edge.  It would be nice if doing this wasn't so difficult.

nophead wrote

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

I round most of my corners and it only needs trig, not calculus, because I
only round with tangential circles. I don't see a need for higher order
curvature continuity.

I do use an iterative solver for positioning pulleys and belts because
there isn't algebraic solution, surprisingly.

On Thu, 3 Oct 2019 at 12:56, adrianv avm4@cornell.edu wrote:

On Thu, Oct 3, 2019, at 12:03 PM, adrianv wrote:

What would be even better was if OpenSCAD had operations for rounding and edge treatment that finish before the heat death of the universe. It's definitely possible to implement, and it's definitely useful. Lots of other CAD programs have these operations. It's arguably a missing feature that OpenSCAD should have.

In Curv, I have special version of union, intersection and difference that add "treatment" to the corners and edges generated by these operations. The two most useful are "smooth", which generates rounded fillets and rounded edges, and "chamfer". I don't have to do any math, I just need to specify the radius over which the edge treatment is applied. I use these operations a lot.

In Curv, at least, these operations are fast. I think that Minkowski sum is inherently expensive, because it requires global knowledge: in principle you are comparing every point in shape A with every point in shape B. But with, for example, my rounded intersection operator, the intersection operator "knows" where the new edges are being generated as the two shapes are intersected, so rounding those edges doesn't require global knowledge. So these kinds of operations can be fast.

In OpenSCAD, I don't think it is possible to implement these operations within the language itself, because you don't have access to the triangle mesh of a shape. So we would have to either fix that (which is being discussed in another thread), or implement these operations in C++ and add them to the core language.

In Shadowwynd's example below, the problem is solved if you can query the bounding box of a text object.

In Curv, every primitive shape operation computes the bounding box of the shape, and makes that bounding box available to the program. This is fast, because it is done without rendering the shape. In the case of intersection and difference, the bounding box is an estimate (the true bounding box might be smaller), but in other cases, the bounding box is exact. In practice, it is these "other cases" where the bounding box is most useful, so it doesn't matter that the bounding box is sometimes an approximation.

This feature could be added to OpenSCAD, with restrictions that guarantee it is a fast operation, and it would not be difficult. In the case of text, the cost of computing the bounding box should be no worse than the cost of previewing the text, and that seems to be a fast enough operation. Since intersection and difference are super expensive to render, you use an approximation for these cases. For intersection(){A;B}, you use the intersection of the bounding boxes of A and B. For difference(){A;B} you just use the bounding box of A.

The bounding box is useful in lots of other situations. Eg, import an STL and position it so that the bottom is at Z==0.

Doug Moen.

On Thu, Oct 3, 2019, at 1:08 PM, shadowwynd wrote:

nophead wrote

Computing the tangent to a curve is calculus, e.g. to create a tangential
circle.

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

circle.

Yes for a general curve but for a circle it is just trig.

I agree that we should be able to query the size of text because it depends
on the font. And we should be able to query the bounds of import STLs
because again it is not something we can specify.

Minkowski should be fast for convex shapes because all you need to do is
hull the sums of all the pairs of points. For a concave shape you need to
decompose it into convex shapes and union the hulls. I think this what
takes forever in CGAL.

On Thu, 3 Oct 2019 at 14:55, adrianv avm4@cornell.edu wrote:

On 03.10.19 15:08, shadowwynd wrote:

Specifically this and also all the other imports are
the most often asked candidates for querying geometry.
The thing is those are the most easy ones that can live
without as the data already exists and does not depend
on calculated geometry.

However to get the data out we need some more basic
ground work to be done in the language that allows the
data to be presented without ugly hacks that can never
be fixed.

I believe the changes to the parser that are currently
in progress plus the "objects" proposal from Doug should
allow import and text (and maybe others) to be used in
a function context returning an object that has both
the geometry as right now and also the additional raw
data about the glyphs.

While that is not a fully general solution, it should
cover quite a number of use cases while still fitting
into the OpenSCAD language without awkward and strange
workarounds.

If that all works out as I think remains to be seen
and also depends on the time that can be dedicated to
this.

ciao,
Torsten.