Nabble removed Mailing-list integration from the Forum.
This killed the Forum. This is now an ARCHIVE.
It is likely Nabble will shutdown in the future.

So basically the Forum is now out of date, we are looking into migrating the history.

OpenSCAD support is now provided by the Mailing List.
See the first pinned post here for instructions on subscribing to the mailing list.

Difference between modelling with Openscad and Freecad

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Difference between modelling with Openscad and Freecad

nophead
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 <[hidden email]> 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 <[hidden email]> 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
> [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

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

Re: Difference between modelling with Openscad and Freecad

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

On Thu, 3 Oct 2019, 07:34 nop head, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [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
_______________________________________________
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: Difference between modelling with Openscad and Freecad

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

Re: Difference between modelling with Openscad and Freecad

nophead
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 <[hidden email]> 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
[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: Difference between modelling with Openscad and Freecad

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

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

Re: Difference between modelling with Openscad and Freecad

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

Re: Difference between modelling with Openscad and Freecad

doug.moen
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
> [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: Difference between modelling with Openscad and Freecad

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

Re: Difference between modelling with Openscad and Freecad

nophead
>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 <[hidden email]> 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
[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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Difference between modelling with Openscad and Freecad

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

_______________________________________________
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: Difference between modelling with Openscad and Freecad

acwest
A render function that returns geometries would also be handy

On Thu, 3 Oct 2019, 10:53 Torsten Paul, <[hidden email]> wrote:
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.

_______________________________________________
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: Difference between modelling with Openscad and Freecad

cacb
In reply to this post by shadowwynd
On 2019-10-03 15:08, 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.

That example is a close match to my sign generator with AngelCAD:
https://gist.github.com/arnholm/23c482530fd1882c615f5e6e3c9eedca

> The train-derailing starts with this simple question:  what are the
> dimensions of the rectangle?

In the above example it is done by first computing the bounding box of
the resulting text and position and size the rectangle based on that.

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: Difference between modelling with Openscad and Freecad

Robin2
In reply to this post by shadowwynd
shadowwynd wrote
> Or you can size/scale it to fit a standard size fob, which distorts the
> font.  

Might it not make more sense to say "that's all Openscad is capable of".

Would a more perfect solution be used sufficiently often to justify the time
that would be required to implement it?


To my mind the attraction of Openscad is the ease with which it can be
learned. I am perfectly happy to live with some limitations on its
capability.

The important thing is to list the limitations up-front so that someone does
not waste time learning it and then run into a brick wall when they should
have given their time to learning a more traditional CAD program.

...R



--
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: Difference between modelling with Openscad and Freecad

OpenSCAD mailing list
In reply to this post by nophead
@nophead

I read but did not totally follow your plan for how you would do the 'robot
arm, ring example'
I am re-reading also studying-up on some points of OpenSCAD, now....

I am mostly a casual user and I am sure the issue is my inexperience with
the language.  I have not really used OpenSCAD functions and I am only now
learning how the 'children' process works and as for using 'multmatrix' I
have never felt the need to use it, or maybe I did but didn't know it.

Do you have some simple code you could post that would show how you use
functions and positioning modules to achieve this?  Obviously it doesn't
have to actually contain complex objects even simple rectangular cubes as
place holders would suffice.  What I want to see is how you would nest these
positioning modules and use functions to feed position modules and return
positions to other modules needing the position information.

I would still like some ability to query objects, especially those that form
hard to compute (for me) angles or positions where I need to insert items.
Using the method you outline might suffice for many things that are done
100% OpenSCAD.

TIA




--
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: Difference between modelling with Openscad and Freecad

nophead
There is a real world example here:  https://github.com/nophead/NopSCADlib/blob/master/printed/fixing_block.scad#L49

I have parametric fixing blocks with three screws positions.



I have functions that return the transformation matrices to get from the block's origin to the screw positions. 
function fixing_block_h_hole(screw = def_screw) = translate(fixing_block_depth(screw) / 2) * rotate([90, 0, 0]); //! Returns transform to position the horizontal screw
function fixing_block_v_holes(screw = def_screw) = //! Returns a list of transforms to position the vertical screws
    let(pitch =  2 * insert_outer_d(screw_insert(screw)) + 2 * wall, offset = fixing_block_depth(screw) / 2)
        [for(end = [-1, 1]) translate([end * pitch / 2, offset]) * rotate([180, 0, 0])];

function fixing_block_holes(screw) = concat([fixing_block_h_hole(screw)], fixing_block_v_holes(screw)); //! Returns a list of transforms to position all the screws
Those functions are normally called by modules to place children at those positions. 
module fixing_block_h_hole(screw = def_screw) //! Position children on the horizontal hole
    multmatrix(fixing_block_h_hole(screw))
        children();

module fixing_block_v_holes(screw = def_screw) //! Position children on the vertical holes
    for(p = fixing_block_v_holes(screw))
        multmatrix(p)
            children();

module fixing_block_holes(screw = def_screw) //! Position children on all the holes
    for(p = fixing_block_holes(screw))
        multmatrix(p)
            children();
These positioning modules are used to drill the holes in the block, place the inserts in the holes and place the screws. 
module fixing_block_assembly(screw = def_screw) //! Printed part with the inserts inserted
assembly(str("fixing_block_M", 20 * screw_radius(screw))) {
    translate_z(fixing_block_height(screw))
        rotate([0, 180, 0])
            color(pp1_colour) render() fixing_block(screw);

    insert = screw_insert(screw);

    fixing_block_v_holes(screw)
        insert(insert);

    fixing_block_h_hole(screw)
        insert(insert);
}
They can also be used to drill holes in the panels they fasten to but there is a problem: the positioning is 3D, but for speed I design my sheets in 2D. Originally I projected the holes to 2D but that is also slow.



My final solution was to factor out the position to functions that return transformation matrices. Then when I design a box I build lists of these transformation for all the fixing blocks in the box. For each panel I then run through the list to see if they place a drill on the surface of the sheet and if so position a circle to subtract from the sheet. I.e. I do the projection myself because CGAL is too slow.

Here I build a list transforms to position all the blocks: https://github.com/nophead/NopSCADlib/blob/master/printed/butt_box.scad#L74

With this function I multiply all the block positions by the screw positions to get a list of all the block holes positions for the box:

function side_holes(type) = [for(p = fixing_block_positions(type), q = fixing_block_holes(bbox_screw(type))) p * q]; 

 Here, given the position of the sheet as a transform, I check if hole is on the sheet, and if so drill it.

module drill_holes(type, t)  
for(list = [corner_holes(type), side_holes(type)], p = list)  
let(q = t * p)  
if(abs(transform([0, 0, 0], q).z) < eps)
multmatrix(q) 
drill(screw_clearance_radius(bbox_screw(type)), 0); 

For each sheet I make a 2D object with the holes drilled in it.
 
module bbox_base_blank(type) { //! 2D template for the base
    dxf(str(bbox_name(type), "_base"));

    difference() {
        sheet_2D(bbox_base_sheet(type), bbox_width(type), bbox_depth(type), 1);

        drill_holes(type, translate(bbox_height(type) / 2));
    }
}
Most of my objects are not this complicated though. They mostly just have have modules to position their children with translate and rotate. If an object only has screws in the Z plane then the positioning modules work for both 2D and 3D. E.g.

module iec_screw_positions(type) //! Position children at the screw holes
    for(side = [-1, 1])
        translate([side * iec_pitch(type) / 2, 0])
            children();

module iec_inserts(type) {              //! Place the inserts
    insert = screw_insert(iec_screw(type));

    iec_screw_positions(type)
        insert(insert);
}


On Thu, 3 Oct 2019 at 21:30, macdarren via Discuss <[hidden email]> wrote:
@nophead

I read but did not totally follow your plan for how you would do the 'robot
arm, ring example'
I am re-reading also studying-up on some points of OpenSCAD, now....

I am mostly a casual user and I am sure the issue is my inexperience with
the language.  I have not really used OpenSCAD functions and I am only now
learning how the 'children' process works and as for using 'multmatrix' I
have never felt the need to use it, or maybe I did but didn't know it.

Do you have some simple code you could post that would show how you use
functions and positioning modules to achieve this?  Obviously it doesn't
have to actually contain complex objects even simple rectangular cubes as
place holders would suffice.  What I want to see is how you would nest these
positioning modules and use functions to feed position modules and return
positions to other modules needing the position information.

I would still like some ability to query objects, especially those that form
hard to compute (for me) angles or positions where I need to insert items.
Using the method you outline might suffice for many things that are done
100% OpenSCAD.

TIA




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

_______________________________________________
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: Difference between modelling with Openscad and Freecad

JordanBrown
In reply to this post by shadowwynd
[ dimensions of text ]

Text is kind of a special case, in that its dimensions do not straightforwardly depend on the inputs.  (The same is true of the boolean operations, but text metrics don't exactly depend on geometry.)

The "text metrics" problem would be solved by a function that accepted the same parameters as text() and returned a vector of metrics.


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

Re: Difference between modelling with Openscad and Freecad

Steven Dick
I think the "query geometry" problem would probably be almost
completely solved with the bounding box of the output from render, or
something similar, especially if you can apply a rotation matrix to
the bounding box or to the object first.

This still doesn't help me snap to a tangent of a curve at an
intersection, but small steps...

On Thu, Oct 3, 2019 at 7:48 PM Jordan Brown
<[hidden email]> wrote:

>
> [ dimensions of text ]
>
>
> Text is kind of a special case, in that its dimensions do not straightforwardly depend on the inputs.  (The same is true of the boolean operations, but text metrics don't exactly depend on geometry.)
>
> The "text metrics" problem would be solved by a function that accepted the same parameters as text() and returned a vector of metrics.
>
> _______________________________________________
> 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: Difference between modelling with Openscad and Freecad

bradipao
In reply to this post by nophead
In a recent design, I found that "text" can be usefully managed using
"resize". And its capability is useful (for the same reason) to imported STL
of unknown size (or size that has to be precisely assigned in openscad).

For example "resize" allows to explicitly resize an object on X axis,
proportionally auto-resize on Y axis, and not resize on Z axis.

resize([10,0,0], auto=[true,true,false]) cube([5,4,1]);



--
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: Difference between modelling with Openscad and Freecad

shadowwynd
Oh, I know resize, which is why I gave the example of:
name="Ro"
name="Pippinpaddleopsicopolis"

- one way or another, resize doesn't work well here.  Yes, this is a "made
up" example - I am not losing any sleep over 3d printing key fobs, but it is
an example of hitting a hard wall early in the sandbox that forces the user
to choose between ugly fudge factors (that are not derivable from pure
mathematics) or ugly output (see example below).

For instance, if I take a cube and rotate it 42° about the X axis, I can,
with trig, calculate the position of the top vertex.  While this would be
much easier with some sort of [xmin,xmax,ymin,ymax,zmin,zmax] = bounds()
rotate([45,0,0]) cube(10); construction, it is perfectly doable via
(reasonably) simple math.

The problem is that OpenSCAD has operations that can not be calculated this
way (text(), surface(), import(), rands() (depending on usage), etc.) and
boolean/offset/minkowski operations in which the bounding box calculation
get downright freakish.

------

module tag(name, multiplier=7)
{
        size = (len(name)*multiplier);

        linear_extrude(2) resize ([size, 10, 0], auto=true) text(name,
valign="center");
        difference()
        {
                color("yellow") translate ([-10, -10, 0]) cube ([10+size+5, 20, 1]);
                translate ([-6, 0, -1]) cylinder (d=4, h=10, $fn=20, center=true);
        }
}

tag("ro");
translate ([0, 25, 0]) tag("Pippinpaddleopsicopolis", 5);

<http://forum.openscad.org/file/t486/pippinpaddle.png>











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

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