Difference between modelling with Openscad and Freecad
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:
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:
Neat solutions, nophead, but, as I said, it can be done in other ways,
but
sometimes, it would be nice to do be able to ask objects for their
properties. Syntactical sugar has its place as well.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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:
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:
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:
Neat solutions, nophead, but, as I said, it can be done in other ways,
but
sometimes, it would be nice to do be able to ask objects for their
properties. Syntactical sugar has its place as well.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
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?
--
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:
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
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?
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Thu, Oct 3, 2019, at 12:03 PM, adrianv 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.
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.
Here's a simple example of why querying geometry would be useful. Imagine a
rectangular key fob with the person's name extruded above the rectangular
backing, and a 5mm margin on every side between the text and the rectangle.
This is very much a "hello world" problem, and I see many kids doing this as
a "my first 3d print" introduction.
The train-derailing starts with this simple question: what are the
dimensions of the rectangle?
And yes, it is easy to manually adjust a number and refresh until it "looks"
right - but this fight is about querying geometry and having computers ...
well, compute.
So the code starts off easy enough:
name = "Fred";
linear_extrude(2) text(name);
With a monospaced font, the size of the rectangle is easy, but not trivial -
we can resize our height to fit a given fob height, calculate the number of
characters in name with len(), multiply by some constant, add 5+x+5mm, and
now we have the dimensions of the fob to create. I do this with Braille
tags, which are monospaced with a set width and height - no big issues.
But text() allows the user to pick a size, and to pick any font that is
installed on the PC, including proportional fonts that are not monospaced.
You can guess at it, you can do a character count - but without decoding the
font file itself and building a table that lets you add up the character
widths for a particular proportional font you have to enter constants for
width and height until it "looks right". Or you can size/scale it to fit a
standard size fob, which distorts the font. Or you decide you want a
different font and you have to start manually calculating a new font width
table, just like you DON'T DO in all other graphic design / word processor
programs. You could just try setting length of fob and let one side have an
uneven margin, but then Murphy will smile on you and you end up with both a
name="Ro" and name="Pippinpaddleopsicopolis" in the same class.
There isn't a way to programatically calculate the size of the fob given a
random proportional font because OpenSCAD doesn't allow geometry queries on
the text object that OpenSCAD generated. And yes, I know how the render
pipeline works, and know that getting the dimensions would require the
object being queried to be rendered first, and there would be a performance
hit, etc.
--
Sent from: http://forum.openscad.org/
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:
Here's a simple example of why querying geometry would be useful. Imagine a
rectangular key fob with the person's name extruded above the rectangular
backing, and a 5mm margin on every side between the text and the rectangle.
This is very much a "hello world" problem, and I see many kids doing this as
a "my first 3d print" introduction.
The train-derailing starts with this simple question: what are the
dimensions of the rectangle?
And yes, it is easy to manually adjust a number and refresh until it "looks"
right - but this fight is about querying geometry and having computers ...
well, compute.
So the code starts off easy enough:
name = "Fred";
linear_extrude(2) text(name);
With a monospaced font, the size of the rectangle is easy, but not trivial -
we can resize our height to fit a given fob height, calculate the number of
characters in name with len(), multiply by some constant, add 5+x+5mm, and
now we have the dimensions of the fob to create. I do this with Braille
tags, which are monospaced with a set width and height - no big issues.
But text() allows the user to pick a size, and to pick any font that is
installed on the PC, including proportional fonts that are not monospaced.
You can guess at it, you can do a character count - but without decoding the
font file itself and building a table that lets you add up the character
widths for a particular proportional font you have to enter constants for
width and height until it "looks right". Or you can size/scale it to fit a
standard size fob, which distorts the font. Or you decide you want a
different font and you have to start manually calculating a new font width
table, just like you DON'T DO in all other graphic design / word processor
programs. You could just try setting length of fob and let one side have an
uneven margin, but then Murphy will smile on you and you end up with both a
name="Ro" and name="Pippinpaddleopsicopolis" in the same class.
There isn't a way to programatically calculate the size of the fob given a
random proportional font because OpenSCAD doesn't allow geometry queries on
the text object that OpenSCAD generated. And yes, I know how the render
pipeline works, and know that getting the dimensions would require the
object being queried to be rendered first, and there would be a performance
hit, etc.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
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.
Computing the tangent to a curve is calculus, e.g. to create a tangential
circle.
--
Sent from: http://forum.openscad.org/
Computing the tangent to a curve is calculus, e.g. to create a tangential
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:
nophead wrote
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.
Computing the tangent to a curve is calculus, e.g. to create a tangential
circle.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 03.10.19 15:08, shadowwynd wrote:
name = "Fred";
linear_extrude(2) text(name);
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.