discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Does Minkowski work only in 2d?

CA
Carsten Arnholm
Mon, Mar 7, 2016 9:11 PM

I am having a look at Minkowski and observe that the documentation isn't
all that clear on this question. The manual mentions this example

$fn=50;
minkowski()
{
cube([10,10,1]);
cylinder(r=2,h=1);
}

Which appears to demonstrate Minkowski working on 3d objects. However,
if you try

$fn=50;
minkowski()
{
translate([0,0,10])cube([10,10,1]);
cylinder(r=2,h=1);
}

... all you get is the same result translated upwards. The exact same
thing happens if you translate the cylinder instead of the cube, which
means this isn't really working in 3d.

If you try

$fn=50;
minkowski()
{
translate([0,0,-10]) cube([10,10,1]);
translate([0,0,10]) cylinder(r=2,h=1);
}

You are back to the original result. The two translations cancel each
other out!

But then, if you try

$fn=50;
minkowski()
{
translate([0,0,-10]) cube([10,10,1]);
translate([0,0,10]) cylinder(r=2,h=1);
}

you get something that looks more like an odd 3d hull operation.

Finally, some creative stuff to possibly igure out what is happening:

$fn=50;
minkowski()
{
cube([10,10,0.000000001]);
rotate([90,0,0])
difference() {
cylinder(r=2,h=1);
translate([1,0,0])cylinder(r=1.5,h=3,center=true);
}
}

It looks like the second object is now swept along the edge of the first
object, and the area between is almost like a hull. However, if you
switch the order, the result is the same...

Is there a more detailed description somewhere on how this really works?
Are these examples well defined?

Carsten Arnholm

I am having a look at Minkowski and observe that the documentation isn't all that clear on this question. The manual mentions this example $fn=50; minkowski() { cube([10,10,1]); cylinder(r=2,h=1); } Which appears to demonstrate Minkowski working on 3d objects. However, if you try $fn=50; minkowski() { translate([0,0,10])cube([10,10,1]); cylinder(r=2,h=1); } ... all you get is the same result translated upwards. The exact same thing happens if you translate the cylinder instead of the cube, which means this isn't really working in 3d. If you try $fn=50; minkowski() { translate([0,0,-10]) cube([10,10,1]); translate([0,0,10]) cylinder(r=2,h=1); } You are back to the original result. The two translations cancel each other out! But then, if you try $fn=50; minkowski() { translate([0,0,-10]) cube([10,10,1]); translate([0,0,10]) cylinder(r=2,h=1); } you get something that looks more like an odd 3d hull operation. Finally, some creative stuff to possibly igure out what is happening: $fn=50; minkowski() { cube([10,10,0.000000001]); rotate([90,0,0]) difference() { cylinder(r=2,h=1); translate([1,0,0])cylinder(r=1.5,h=3,center=true); } } It looks like the second object is now swept along the edge of the first object, and the area between is almost like a hull. However, if you switch the order, the result is the same... Is there a more detailed description somewhere on how this really works? Are these examples well defined? Carsten Arnholm
CA
Carsten Arnholm
Mon, Mar 7, 2016 9:18 PM

Sorry, there was a typo

On 07. mars 2016 22:11, Carsten Arnholm wrote:

But then, if you try

$fn=50;
minkowski()
{
translate([0,0,-10]) cube([10,10,1]);
translate([0,0,10]) cylinder(r=2,h=1);
}

you get something that looks more like an odd 3d hull operation.

It was supposed to be

$fn=50;
minkowski()
{
rotate([30,0,0]) cube([10,10,1]);
translate([0,0,10]) cylinder(r=2,h=1);
}

Carsten Arnholm

Sorry, there was a typo On 07. mars 2016 22:11, Carsten Arnholm wrote: > But then, if you try > > $fn=50; > minkowski() > { > translate([0,0,-10]) cube([10,10,1]); > translate([0,0,10]) cylinder(r=2,h=1); > } > > you get something that looks more like an odd 3d hull operation. > It was supposed to be $fn=50; minkowski() { rotate([30,0,0]) cube([10,10,1]); translate([0,0,10]) cylinder(r=2,h=1); } Carsten Arnholm
P
Parkinbot
Mon, Mar 7, 2016 11:16 PM

You can regard minkowski as an inner product. Which "natural" 3D semantics
would you expect when translations are inserted?

but try this:

$fn=50;
minkowski()
{
rotate([45, 45, 0])
cube([10,10,1]);
cylinder(r=2,h=1);
}

or this:

$fn=50;
minkowski()
{
rotate([45, 45, 0])
cube([10,10,1]);
scale([2, 1, 1])
cylinder(r=2,h=1);
}

--
View this message in context: http://forum.openscad.org/Does-Minkowski-work-only-in-2d-tp16334p16338.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

You can regard minkowski as an inner product. Which "natural" 3D semantics would you expect when translations are inserted? but try this: $fn=50; minkowski() { rotate([45, 45, 0]) cube([10,10,1]); cylinder(r=2,h=1); } or this: $fn=50; minkowski() { rotate([45, 45, 0]) cube([10,10,1]); scale([2, 1, 1]) cylinder(r=2,h=1); } -- View this message in context: http://forum.openscad.org/Does-Minkowski-work-only-in-2d-tp16334p16338.html Sent from the OpenSCAD mailing list archive at Nabble.com.
NH
nop head
Tue, Mar 8, 2016 12:01 AM

It looks like the second object is now swept along the edge of the first
object, and the area between is almost like a hull. However, if you switch
the order, the result is the same...

A Minkowski sum is commutative so yes if you swap the order you get the
same result.

Is there a more detailed description somewhere on how this really works?

Are these examples well defined?

Yes it is well defined mathematically, see
https://en.wikipedia.org/wiki/Minkowski_addition.

Basically if you think of the origin of one object swept along all the
edges of the other object and unioned together that is the result. All your
examples do what I expect.

On 7 March 2016 at 23:16, Parkinbot rudolf@parkinbot.com wrote:

You can regard minkowski as an inner product. Which "natural" 3D semantics
would you expect when translations are inserted?

but try this:

$fn=50;
minkowski()
{
rotate([45, 45, 0])
cube([10,10,1]);
cylinder(r=2,h=1);
}

or this:

$fn=50;
minkowski()
{
rotate([45, 45, 0])
cube([10,10,1]);
scale([2, 1, 1])
cylinder(r=2,h=1);
}

--
View this message in context:
http://forum.openscad.org/Does-Minkowski-work-only-in-2d-tp16334p16338.html
Sent from the OpenSCAD mailing list archive at Nabble.com.


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

> > It looks like the second object is now swept along the edge of the first > object, and the area between is almost like a hull. However, if you switch > the order, the result is the same... > A Minkowski sum is commutative so yes if you swap the order you get the same result. Is there a more detailed description somewhere on how this really works? > Are these examples well defined? > Yes it is well defined mathematically, see https://en.wikipedia.org/wiki/Minkowski_addition. Basically if you think of the origin of one object swept along all the edges of the other object and unioned together that is the result. All your examples do what I expect. On 7 March 2016 at 23:16, Parkinbot <rudolf@parkinbot.com> wrote: > You can regard minkowski as an inner product. Which "natural" 3D semantics > would you expect when translations are inserted? > > but try this: > > $fn=50; > minkowski() > { > rotate([45, 45, 0]) > cube([10,10,1]); > cylinder(r=2,h=1); > } > > or this: > > $fn=50; > minkowski() > { > rotate([45, 45, 0]) > cube([10,10,1]); > scale([2, 1, 1]) > cylinder(r=2,h=1); > } > > > > > -- > View this message in context: > http://forum.openscad.org/Does-Minkowski-work-only-in-2d-tp16334p16338.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
A
arnholm@arnholm.org
Tue, Mar 8, 2016 6:15 AM

On 2016-03-08 00:16, Parkinbot wrote:

You can regard minkowski as an inner product. Which "natural" 3D
semantics
would you expect when translations are inserted?

What do you mean by inner product in this context? I don't have a lot of
expectations, but rather trying to understand the definition so I can
establish expectations of how this is supposed to work.

On 2016-03-08 00:16, Parkinbot wrote: > You can regard minkowski as an inner product. Which "natural" 3D > semantics > would you expect when translations are inserted? What do you mean by inner product in this context? I don't have a lot of expectations, but rather trying to understand the definition so I can establish expectations of how this is supposed to work.
NH
nop head
Tue, Mar 8, 2016 8:59 AM

The definition in simple terms is that the origin of the first object is
placed at every point inside the second object and the results unioned. Of
course that would be an infinite number unless the object was divided into
voxels.

In practice you get exactly the same result sweeping the origin of the
first object along all the edges of the second object. Again infinite but
less so ;-)

If the object is convex than you can place the origin of the first object
at all of the vertices of the second object and take the convex hull. This
is now finite to compute as it is just a hull of all the vertices of one
object added to all the vertices of the other object. This is why you said
some of the results look like a hull. They are. And since vector addition
is commutative, so is Minkowski.

To do Minkowski on concave objects you need to decompose them into multiple
convex ones, do convex Minkowski on those and then union the results.

On 8 March 2016 at 06:15, arnholm@arnholm.org wrote:

On 2016-03-08 00:16, Parkinbot wrote:

You can regard minkowski as an inner product. Which "natural" 3D semantics
would you expect when translations are inserted?

What do you mean by inner product in this context? I don't have a lot of
expectations, but rather trying to understand the definition so I can
establish expectations of how this is supposed to work.


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

The definition in simple terms is that the origin of the first object is placed at every point inside the second object and the results unioned. Of course that would be an infinite number unless the object was divided into voxels. In practice you get exactly the same result sweeping the origin of the first object along all the edges of the second object. Again infinite but less so ;-) If the object is convex than you can place the origin of the first object at all of the vertices of the second object and take the convex hull. This is now finite to compute as it is just a hull of all the vertices of one object added to all the vertices of the other object. This is why you said some of the results look like a hull. They are. And since vector addition is commutative, so is Minkowski. To do Minkowski on concave objects you need to decompose them into multiple convex ones, do convex Minkowski on those and then union the results. On 8 March 2016 at 06:15, <arnholm@arnholm.org> wrote: > On 2016-03-08 00:16, Parkinbot wrote: > >> You can regard minkowski as an inner product. Which "natural" 3D semantics >> would you expect when translations are inserted? >> > > What do you mean by inner product in this context? I don't have a lot of > expectations, but rather trying to understand the definition so I can > establish expectations of how this is supposed to work. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
TP
Torsten Paul
Tue, Mar 8, 2016 9:35 AM

Von: "nop head" nop.head@gmail.com

If the object is convex than you can place the origin of
the first object at all of the vertices of the second object
and take the convex hull. This is now finite to compute as
it is just a hull of all the vertices of one object added
to all the vertices of the other object. This is why you
said some of the results look like a hull. They are. And
since vector addition is commutative, so is Minkowski. 

Yep, that's exactly how it's implemented now. IIRC that
was the optimization Oskar did some time ago.
It uses CGAL to do a convex decomposition and then creates
the convex minkowski meshes and unions those together again.

This is the reason why minkowski now can be very fast if
the convex decomposition produces only a small number of
parts while object like a cube with a sphere cut out are
quite slow as there's a huge performance hit with the final
union operation.

ciao,
Torsten.

Von: "nop head" <nop.head@gmail.com> > If the object is convex than you can place the origin of > the first object at all of the vertices of the second object > and take the convex hull. This is now finite to compute as > it is just a hull of all the vertices of one object added > to all the vertices of the other object. This is why you > said some of the results look like a hull. They are. And > since vector addition is commutative, so is Minkowski.  > Yep, that's exactly how it's implemented now. IIRC that was the optimization Oskar did some time ago. It uses CGAL to do a convex decomposition and then creates the convex minkowski meshes and unions those together again. This is the reason why minkowski now can be very fast if the convex decomposition produces only a small number of parts while object like a cube with a sphere cut out are quite slow as there's a huge performance hit with the final union operation. ciao, Torsten.
DM
doug moen
Tue, Mar 8, 2016 12:21 PM

Nop Head said: The definition in simple terms is that the origin of the
first object is placed at every point inside the second object and the
results unioned. Of course that would be an infinite number unless the
object was divided into voxels.

It's not just the origin. Every point within the first object is aligned
with every point within the second object and the results unioned.

If you combine a cube of size 10 with a sphere of diameter 10, you'll get a
rounded cube of size 30.

On Tuesday, 8 March 2016, nop head nop.head@gmail.com wrote:

The definition in simple terms is that the origin of the first object is
placed at every point inside the second object and the results unioned. Of
course that would be an infinite number unless the object was divided into
voxels.

In practice you get exactly the same result sweeping the origin of the
first object along all the edges of the second object. Again infinite but
less so ;-)

If the object is convex than you can place the origin of the first object
at all of the vertices of the second object and take the convex hull. This
is now finite to compute as it is just a hull of all the vertices of one
object added to all the vertices of the other object. This is why you said
some of the results look like a hull. They are. And since vector addition
is commutative, so is Minkowski.

To do Minkowski on concave objects you need to decompose them into
multiple convex ones, do convex Minkowski on those and then union the
results.

On 8 March 2016 at 06:15, <arnholm@arnholm.org
javascript:_e(%7B%7D,'cvml','arnholm@arnholm.org');> wrote:

On 2016-03-08 00:16, Parkinbot wrote:

You can regard minkowski as an inner product. Which "natural" 3D
semantics
would you expect when translations are inserted?

What do you mean by inner product in this context? I don't have a lot of
expectations, but rather trying to understand the definition so I can
establish expectations of how this is supposed to work.


OpenSCAD mailing list
Discuss@lists.openscad.org
javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Nop Head said: The definition in simple terms is that the origin of the first object is placed at every point inside the second object and the results unioned. Of course that would be an infinite number unless the object was divided into voxels. It's not just the origin. Every point within the first object is aligned with every point within the second object and the results unioned. If you combine a cube of size 10 with a sphere of diameter 10, you'll get a rounded cube of size 30. On Tuesday, 8 March 2016, nop head <nop.head@gmail.com> wrote: > The definition in simple terms is that the origin of the first object is > placed at every point inside the second object and the results unioned. Of > course that would be an infinite number unless the object was divided into > voxels. > > In practice you get exactly the same result sweeping the origin of the > first object along all the edges of the second object. Again infinite but > less so ;-) > > If the object is convex than you can place the origin of the first object > at all of the vertices of the second object and take the convex hull. This > is now finite to compute as it is just a hull of all the vertices of one > object added to all the vertices of the other object. This is why you said > some of the results look like a hull. They are. And since vector addition > is commutative, so is Minkowski. > > To do Minkowski on concave objects you need to decompose them into > multiple convex ones, do convex Minkowski on those and then union the > results. > > > > > On 8 March 2016 at 06:15, <arnholm@arnholm.org > <javascript:_e(%7B%7D,'cvml','arnholm@arnholm.org');>> wrote: > >> On 2016-03-08 00:16, Parkinbot wrote: >> >>> You can regard minkowski as an inner product. Which "natural" 3D >>> semantics >>> would you expect when translations are inserted? >>> >> >> What do you mean by inner product in this context? I don't have a lot of >> expectations, but rather trying to understand the definition so I can >> establish expectations of how this is supposed to work. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > >
NH
nop head
Tue, Mar 8, 2016 12:47 PM

No that is wrong.

minkowski() {
cube(10, center = true);
sphere(d =10);

}

Gives a rounded  20mm cube.


If you consider each vertex to be a vector then every possible pair of
vertices are added and the resulting points are hulled. The vertices are
not aligned, they are summed. That is the same as saying the origin of one
object is offset by the vertices of the other.

On 8 March 2016 at 12:21, doug moen doug@moens.org wrote:

Nop Head said: The definition in simple terms is that the origin of the
first object is placed at every point inside the second object and the
results unioned. Of course that would be an infinite number unless the
object was divided into voxels.

It's not just the origin. Every point within the first object is aligned
with every point within the second object and the results unioned.

If you combine a cube of size 10 with a sphere of diameter 10, you'll get
a rounded cube of size 30.

On Tuesday, 8 March 2016, nop head nop.head@gmail.com wrote:

The definition in simple terms is that the origin of the first object is
placed at every point inside the second object and the results unioned. Of
course that would be an infinite number unless the object was divided into
voxels.

In practice you get exactly the same result sweeping the origin of the
first object along all the edges of the second object. Again infinite but
less so ;-)

If the object is convex than you can place the origin of the first object
at all of the vertices of the second object and take the convex hull. This
is now finite to compute as it is just a hull of all the vertices of one
object added to all the vertices of the other object. This is why you said
some of the results look like a hull. They are. And since vector addition
is commutative, so is Minkowski.

To do Minkowski on concave objects you need to decompose them into
multiple convex ones, do convex Minkowski on those and then union the
results.

On 8 March 2016 at 06:15, arnholm@arnholm.org wrote:

On 2016-03-08 00:16, Parkinbot wrote:

You can regard minkowski as an inner product. Which "natural" 3D
semantics
would you expect when translations are inserted?

What do you mean by inner product in this context? I don't have a lot of
expectations, but rather trying to understand the definition so I can
establish expectations of how this is supposed to work.


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

No that is wrong. minkowski() { cube(10, center = true); sphere(d =10); } Gives a rounded 20mm cube. ​ If you consider each vertex to be a vector then every possible pair of vertices are added and the resulting points are hulled. The vertices are not aligned, they are summed. That is the same as saying the origin of one object is offset by the vertices of the other. On 8 March 2016 at 12:21, doug moen <doug@moens.org> wrote: > Nop Head said: The definition in simple terms is that the origin of the > first object is placed at every point inside the second object and the > results unioned. Of course that would be an infinite number unless the > object was divided into voxels. > > It's not just the origin. Every point within the first object is aligned > with every point within the second object and the results unioned. > > If you combine a cube of size 10 with a sphere of diameter 10, you'll get > a rounded cube of size 30. > > On Tuesday, 8 March 2016, nop head <nop.head@gmail.com> wrote: > >> The definition in simple terms is that the origin of the first object is >> placed at every point inside the second object and the results unioned. Of >> course that would be an infinite number unless the object was divided into >> voxels. >> >> In practice you get exactly the same result sweeping the origin of the >> first object along all the edges of the second object. Again infinite but >> less so ;-) >> >> If the object is convex than you can place the origin of the first object >> at all of the vertices of the second object and take the convex hull. This >> is now finite to compute as it is just a hull of all the vertices of one >> object added to all the vertices of the other object. This is why you said >> some of the results look like a hull. They are. And since vector addition >> is commutative, so is Minkowski. >> >> To do Minkowski on concave objects you need to decompose them into >> multiple convex ones, do convex Minkowski on those and then union the >> results. >> >> >> >> >> On 8 March 2016 at 06:15, <arnholm@arnholm.org> wrote: >> >>> On 2016-03-08 00:16, Parkinbot wrote: >>> >>>> You can regard minkowski as an inner product. Which "natural" 3D >>>> semantics >>>> would you expect when translations are inserted? >>>> >>> >>> What do you mean by inner product in this context? I don't have a lot of >>> expectations, but rather trying to understand the definition so I can >>> establish expectations of how this is supposed to work. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >
NH
nop head
Tue, Mar 8, 2016 12:52 PM

This produces exactly the same result as it is what OpenScad does
internally for convex shapes.

hull()
for(x =[-5, 5], y = [-5, 5], z = [-5, 5])
translate([x, y, z])
sphere(d = 10);

On 8 March 2016 at 12:47, nop head nop.head@gmail.com wrote:

No that is wrong.

minkowski() {
cube(10, center = true);
sphere(d =10);

}

Gives a rounded  20mm cube.


If you consider each vertex to be a vector then every possible pair of
vertices are added and the resulting points are hulled. The vertices are
not aligned, they are summed. That is the same as saying the origin of one
object is offset by the vertices of the other.

On 8 March 2016 at 12:21, doug moen doug@moens.org wrote:

Nop Head said: The definition in simple terms is that the origin of the
first object is placed at every point inside the second object and the
results unioned. Of course that would be an infinite number unless the
object was divided into voxels.

It's not just the origin. Every point within the first object is aligned
with every point within the second object and the results unioned.

If you combine a cube of size 10 with a sphere of diameter 10, you'll get
a rounded cube of size 30.

On Tuesday, 8 March 2016, nop head nop.head@gmail.com wrote:

The definition in simple terms is that the origin of the first object is
placed at every point inside the second object and the results unioned. Of
course that would be an infinite number unless the object was divided into
voxels.

In practice you get exactly the same result sweeping the origin of the
first object along all the edges of the second object. Again infinite but
less so ;-)

If the object is convex than you can place the origin of the first
object at all of the vertices of the second object and take the convex
hull. This is now finite to compute as it is just a hull of all the
vertices of one object added to all the vertices of the other object. This
is why you said some of the results look like a hull. They are. And since
vector addition is commutative, so is Minkowski.

To do Minkowski on concave objects you need to decompose them into
multiple convex ones, do convex Minkowski on those and then union the
results.

On 8 March 2016 at 06:15, arnholm@arnholm.org wrote:

On 2016-03-08 00:16, Parkinbot wrote:

You can regard minkowski as an inner product. Which "natural" 3D
semantics
would you expect when translations are inserted?

What do you mean by inner product in this context? I don't have a lot
of expectations, but rather trying to understand the definition so I can
establish expectations of how this is supposed to work.


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

This produces exactly the same result as it is what OpenScad does internally for convex shapes. hull() for(x =[-5, 5], y = [-5, 5], z = [-5, 5]) translate([x, y, z]) sphere(d = 10); On 8 March 2016 at 12:47, nop head <nop.head@gmail.com> wrote: > No that is wrong. > > minkowski() { > cube(10, center = true); > sphere(d =10); > > } > > Gives a rounded 20mm cube. > > > ​ > If you consider each vertex to be a vector then every possible pair of > vertices are added and the resulting points are hulled. The vertices are > not aligned, they are summed. That is the same as saying the origin of one > object is offset by the vertices of the other. > > On 8 March 2016 at 12:21, doug moen <doug@moens.org> wrote: > >> Nop Head said: The definition in simple terms is that the origin of the >> first object is placed at every point inside the second object and the >> results unioned. Of course that would be an infinite number unless the >> object was divided into voxels. >> >> It's not just the origin. Every point within the first object is aligned >> with every point within the second object and the results unioned. >> >> If you combine a cube of size 10 with a sphere of diameter 10, you'll get >> a rounded cube of size 30. >> >> On Tuesday, 8 March 2016, nop head <nop.head@gmail.com> wrote: >> >>> The definition in simple terms is that the origin of the first object is >>> placed at every point inside the second object and the results unioned. Of >>> course that would be an infinite number unless the object was divided into >>> voxels. >>> >>> In practice you get exactly the same result sweeping the origin of the >>> first object along all the edges of the second object. Again infinite but >>> less so ;-) >>> >>> If the object is convex than you can place the origin of the first >>> object at all of the vertices of the second object and take the convex >>> hull. This is now finite to compute as it is just a hull of all the >>> vertices of one object added to all the vertices of the other object. This >>> is why you said some of the results look like a hull. They are. And since >>> vector addition is commutative, so is Minkowski. >>> >>> To do Minkowski on concave objects you need to decompose them into >>> multiple convex ones, do convex Minkowski on those and then union the >>> results. >>> >>> >>> >>> >>> On 8 March 2016 at 06:15, <arnholm@arnholm.org> wrote: >>> >>>> On 2016-03-08 00:16, Parkinbot wrote: >>>> >>>>> You can regard minkowski as an inner product. Which "natural" 3D >>>>> semantics >>>>> would you expect when translations are inserted? >>>>> >>>> >>>> What do you mean by inner product in this context? I don't have a lot >>>> of expectations, but rather trying to understand the definition so I can >>>> establish expectations of how this is supposed to work. >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >