Rounding convex edges without minkowski?
On 2017-06-05 13:46, caterpillar wrote:
For the same reason, I also created several 2D shapes in my library:)
I keep meaning to use dotSCAD. I have it in my library folder but
haven't (yet) pulled anything from it.
Anyway, here is RoundedBox to go with RoundedRect. All radii the same
currently but there is no need for it to be this way.
function RoundedBox (xsize=10, ysize=10, zsize=10, r=1, fa=$fa) = [
let (zo = (zsize/2)-r)
for (a = [0: fa : 180])
let (xs=xsize-r+sin(a)*r, ys=ysize-r+sin(a)*r)
[ for (e = RoundedRect (xsize=xs, ysize=ys, r=r, fa=fa)) [e[0],
e[1], cos(a)*r + zo * sign(cos(a))] ]
];
// Box
skin (RoundedBox (xsize=10, ysize=20, zsize=30, r=2));
Because it returns a matrix of points, this can be bent around in any
way you like.
I am perfectly aware that we can implement all that stuff on our own - at
least up to the point, where Boolean operations come into play. But isn't it
reinventing the wheel?
Why do I have to write my own affine libraries with hundreds of lines for
stuff that OpenSCAD obviously can/could do in a threeliner? For years now
dozens of people have been asking to get hands on the vertices and almost
every third discussion sooner or later ends up in that blind alley.
--
View this message in context: http://forum.openscad.org/Rounding-convex-edges-without-minkowski-tp21621p21645.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2017-06-05 15:58, Parkinbot wrote:
For years now
dozens of people have been asking to get hands on the vertices and almost
every third discussion sooner or later ends up in that blind alley.
I'm very new to OpenSCAD, but I tend to agree. As it happens, I'm
creating shapes that have too many complex curves to be constructed
without splines+skin, but being able to "reflect" on geometry that's
been created without it disappearing into a black hole once made into
OpenSCAD objects would be rather nice.
On 06/05/2017 04:58 PM, Parkinbot wrote:
I am perfectly aware that we can implement all that stuff
on our own - at least up to the point, where Boolean operations
come into play. But isn't it reinventing the wheel?
At least in part, it is. Although the existence of multiple solution
can help showing what the most common need is.
Why do I have to write my own affine libraries with hundreds of
lines for stuff that OpenSCAD obviously can/could do in a threeliner?
For years now dozens of people have been asking to get hands on the
vertices and almost every third discussion sooner or later ends up
in that blind alley.
I'm asking for an unicorn for years, and still don't have one...
Joke aside, the need for that is clearly there. But it seems
right now there's both not enough development resources to work
on that and also no clear path of how it should look like.
Oskar did quite some initial work with the 2D sweep pull request
(getting a bit dusty by now) and the sweep()/skin() scad-script
implementation on the openscad github.
With now at least 3 different and powerful script implementations,
it might be possible to outline a way how to get to an integrated
solution.
It might be worthwhile not to go for the full "access all data at
any time" approach as that does not match the current evaluation
logic and needs bigger internal changes.
However it might be possible to find a solution that's somewhere
between the current and this full-data-access-anything-is-possible
state. I guess the main challenge (apart from the math for the
3D stuff itself) is to define the data structures and modules
in a way that's not breaking too much existing code and also
makes future changes possible.
Anyone having some spare cycles to help getting that project
going, maybe by collecting the ideas in the github wiki?
ciao,
Torsten.
tp3 wrote
However it might be possible to find a solution that's somewhere
between the current and this full-data-access-anything-is-possible
state. I guess the main challenge (apart from the math for the
3D stuff itself) is to define the data structures and modules
in a way that's not breaking too much existing code and also
makes future changes possible.
The most radical approach would be to generally allow function syntax for
module code and return a vector with two elements, the first listing up the
vertices and the second the faces sets. So that alternatively to
linear_extrude(height = 10, twist=360) square(10, center = true);
we can write
a = linear_extrude(height = 10, twist=360) square(10, center = true);
polyhedron(a[0], a[1]);
Everyone using this syntax will have to be aware that any Boolean operation
will trigger an implicit render() and a call into CGAL:
b = intersection() { cube(10); sphere(10); } -> CGAL
c = { cube(10); sphere(10); } // implicit union -> CGAL
The 2D equivalent will obviously be
d = offset(10) square(10);
polygon(d);
I am aware that this is hard to implement, since OpenSCAD currently
evaluates all functional code before module code is processed, which brings
us back to the scope rules ...
--
View this message in context: http://forum.openscad.org/Rounding-convex-edges-without-minkowski-tp21621p21648.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 06/05/2017 08:50 PM, Parkinbot wrote:
The most radical approach would be to generally allow function syntax for
module code and return a vector with two elements, the first listing up the
vertices and the second the faces sets. So that alternatively to
linear_extrude(height = 10, twist=360) square(10, center = true);
we can write
a = linear_extrude(height = 10, twist=360) square(10, center = true);
polyhedron(a[0], a[1]);
I guess that's basically the big feature that would be cool but I
don't see that happening soon realistically unless someone wins the
lottery and sponsors Marius for the next two years or so ;-). I'd
love to be wrong on that though. Who knows, maybe some University
could get interested to help with some open source work...
That's why I'm thinking a smaller solution might at least cover
some of the most common use cases even if it does not yet provide
the full expressive power possible.
ciao,
Torsten.
Torsten,
There are good proposals to full data access without much implementation
troubles. Issues #1324 https://github.com/openscad/openscad/issues/1324
and #1585 are two examples of them. They are restrict to the data import
of stl file but they don't require any language syntax change just the
implementation of the import() or read() built-in function.
I have been using the polyhedron data structure ([vertices, faces]) in my
codes to build objects bounded by parametric surfaces. In my scheme,
rectangular patches (matrix of points), triangular patches (triangular
matrix of points) and even polygonal faces are converted to polyhedron data
structure by specialized functions and an unique module collects a list of
such data structures and unify them in one data structure as input to one
polyhedron call.
The polyhedron data structure is not the most adequate to support the query
of a solid but it is built in some way as part of a stl file import. Based
on that it would be easy to implement in OpenSCAD codes the computation of
solid volume, surface area, center of mass and also some operations like
non-linear transforms.
Ronaldo
https://github.com/openscad/openscad/issues/1324
2017-06-05 12:25 GMT-03:00 Torsten Paul Torsten.Paul@gmx.de:
On 06/05/2017 04:58 PM, Parkinbot wrote:
I am perfectly aware that we can implement all that stuff
on our own - at least up to the point, where Boolean operations
come into play. But isn't it reinventing the wheel?
At least in part, it is. Although the existence of multiple solution
can help showing what the most common need is.
Why do I have to write my own affine libraries with hundreds of
lines for stuff that OpenSCAD obviously can/could do in a threeliner?
For years now dozens of people have been asking to get hands on the
vertices and almost every third discussion sooner or later ends up
in that blind alley.
I'm asking for an unicorn for years, and still don't have one...
Joke aside, the need for that is clearly there. But it seems
right now there's both not enough development resources to work
on that and also no clear path of how it should look like.
Oskar did quite some initial work with the 2D sweep pull request
(getting a bit dusty by now) and the sweep()/skin() scad-script
implementation on the openscad github.
With now at least 3 different and powerful script implementations,
it might be possible to outline a way how to get to an integrated
solution.
It might be worthwhile not to go for the full "access all data at
any time" approach as that does not match the current evaluation
logic and needs bigger internal changes.
However it might be possible to find a solution that's somewhere
between the current and this full-data-access-anything-is-possible
state. I guess the main challenge (apart from the math for the
3D stuff itself) is to define the data structures and modules
in a way that's not breaking too much existing code and also
makes future changes possible.
Anyone having some spare cycles to help getting that project
going, maybe by collecting the ideas in the github wiki?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I think the probe() proposal fits a lot better into the language and could
allow access to the mesh data. Isn't that already a working pull request?
So minimal work to merge it.
On 5 June 2017 at 20:07, Torsten Paul Torsten.Paul@gmx.de wrote:
On 06/05/2017 08:50 PM, Parkinbot wrote:
The most radical approach would be to generally allow function syntax for
module code and return a vector with two elements, the first listing up
the
vertices and the second the faces sets. So that alternatively to
linear_extrude(height = 10, twist=360) square(10, center = true);
we can write
a = linear_extrude(height = 10, twist=360) square(10, center = true);
polyhedron(a[0], a[1]);
I guess that's basically the big feature that would be cool but I
don't see that happening soon realistically unless someone wins the
lottery and sponsors Marius for the next two years or so ;-). I'd
love to be wrong on that though. Who knows, maybe some University
could get interested to help with some open source work...
That's why I'm thinking a smaller solution might at least cover
some of the most common use cases even if it does not yet provide
the full expressive power possible.
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 06/05/2017 09:19 PM, Ronaldo Persiano wrote:
There are good proposals to full data access without much
implementation troubles. Issues #1324 and #1585 are two
examples of them. They are restrict to the data import of
stl file but they don't require any language syntax change
just the implementation of the import() or read() built-in
function.
Those look like a different discussion to me as they rely
on external data. This seems to target a quite different
category of models.
I'm talking about script features solving things like the
title of the thread says. I guess the biggest pain point
for the casual user (and I tend to include myself here) is
that creating simple fillets/chamfers is lots of work.
One idea I had for 2D was to add TCB spline support to
polygon which is maybe a bit too restrictive. But that
could handle the cases where multiple offset() will not
work, e.g. due to thin geometry.
For 3D there's the awesome fillet script by Andrew aka
clothbot but that suffers too much from the slow CGAL
calculations to just throw it at every case.
So what I mean is that trying to chew on smaller bites
would increase the chances to get something done.
ciao,
Torsten.