Re: center() as transformation function
Of course in native openscad anything is possible, including a center()
operator, if it was desired to implement. But in my experience, wishing
for things to appear in native openscad is a path to disappointment. The
question is what can we do in user space, and right now, implementing a
center operator is impossible. There is a test feature that renders and
passes the geometry from objects into userspace. This would enable a
userspace implementation of centering---and a whole host of great features
as well. Yes, render would run, but I think caching means it would NOT
have to render every time, so it's not as bad as you think.
On Mon, Sep 23, 2024 at 4:07 AM Guenther Sohler via Discuss <
discuss@lists.openscad.org> wrote:
A center() primitive would definitely be possible in OpenSCAD.
Main issue is that OpenSCAD would have to render its child object first to
get its
real bounding box and OpenSCAD does not do that for performance reasons.
Using center() is not clever anyway, because openSCAD would have to render
the object EVERY TIME whereas the user would have to calculate the
translation shift
ONCE, which is much more performant .
On Mon, Sep 23, 2024 at 9:16 AM Peter Kriens via Discuss <
discuss@lists.openscad.org> wrote:
BOSL2 has to work within the limitations of OpenSCAD. Their support for a
generic shape (paths, cubes, prisms, spheres, cylinders, regions, and vnfs)
is quite heroic but it does indeed fall short since you miss some of the
crucial operators like intersect, diff, etc. on the vnfs.
You probably could make a composite shape that would be able to
postpone the operations until you reify the shape. Since the original
shapes would still be available, you could still get the combined set of
anchors. But this screams for an Object Oriented approach to not make it
explode in complexity and it feels that is not something OpenSCAD will want
to have.
Cheers,
Peter
On 21 Sep 2024, at 15:04, Adrian Mariano avm4@cornell.edu wrote:
You're right that you could use vnf_polyhedron, but in the example above,
the compound object was constructed using attachment. Suppose magically we
had vnf_difference() and you wanted to construct the example that was
posted earlier. In that example, attachment was used to place the child
that is differenced away. If you use vnf_polyhedron to convert your two
VNFs into geometry then you cannot get a VNF back out to use the VNF
anchors. So at least as things stand, you'd need to do
vnf_difference(vnf1, transform*vnf2) where transform was computed somehow
to be the transform that performs attachment.
On Sat, Sep 21, 2024 at 2:03 AM Peter Kriens peter.kriens@aqute.biz
wrote:
And the VNF calls don't allow you to use attach() so if you wanted
attachment you'd need to simulate it yourself by applying operators to the
VNFs.
That is not true, vnf_polyhedron() is fully attachable. It calculates
the common anchors and can calculate the vector based on the normals.
On Fri 20 Sep 2024 at 23:53, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
I would make a stronger statement and say that what Jonathan is trying
to do is not merely impractical but impossible. He seems to be hoping that
by asking the cube to be centered, the whole object will be centered, where
everything is being computed as geometry. There is no way BOSL2 could
possibly extract information about the object.
What's impractical is implementing VNF difference. If we could do
that, then we could center objects. But it would have to be done with VNF
generation commands, not with geometry. And the VNF calls don't allow you
to use attach() so if you wanted attachment you'd need to simulate it
yourself by applying operators to the VNFs.
On Fri, Sep 20, 2024 at 5:30 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
[ I should note that I do not mean in the slightest to disparage
BOSL2. Revar and Adrian have done amazing work. But there are some things
that are just not practical. ]
On 9/20/2024 10:03 AM, Jonathan Gilbert via Discuss wrote:
It can definitely create that shape object; and once created, you
can definitely center it:
include <BOSL2/std.scad>
xdistribute(spacing=50) {
difference() {
cube(20, center=true);
cylinder(h=11, d1=0, d2=100);
}
diff()
cuboid(20, anchor=CENTER)
attach(TOP, BOTTOM, overlap=10)
tag("remove")
cyl(h=11, d1=0, d2=100);
}
<image.png>
I don't speak BOSL2 well enough to be sure what you're asking it to
do, but neither of those is centered vertically. (I think that you have
centered the cube, rather than centering the result of the difference.)
You can't really see it from the angle you're showing, but look at this
angle (view from -Y/Front, orthogonal):
<udcR20RffCNm7D8c.png>
The right-hand one is the one you're trying to center; observe it's at
exactly the same position as the left-hand one, and that there's a lot more
below the XY plane than above it.
Here's what it should look like, from exactly that same viewpoint:
<50zG2Uy93oI5Xx4o.png>
(Generated using a PR#4478 experimental, using mechanisms that fully
render the object and make its geometry available to the program.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I think passing the geometry from objects into userspace is a great way
to allow users to extend openscad features, without having to reinvent
the wheels from the bottom up. With manifold, render is not as expensive
as before (except for minkowski, someone should really write a faster
convex decomposition...). Apart from using the geometry cache, for
operations like translate/scaling/union, you don't really need to render
the object to get its bounding box.
On 23/9/2024 18:54, Adrian Mariano via Discuss wrote:
Of course in native openscad anything is possible, including a
center() operator, if it was desired to implement. But in my
experience, wishing for things to appear in native openscad is a path
to disappointment. The question is what can we do in user space, and
right now, implementing a center operator is impossible. There is a
test feature that renders and passes the geometry from objects into
userspace. This would enable a userspace implementation of
centering---and a whole host of great features as well. Yes, render
would run, but I think caching means it would NOT have to render every
time, so it's not as bad as you think.
On Mon, Sep 23, 2024 at 4:07 AM Guenther Sohler via Discuss
discuss@lists.openscad.org wrote:
A center() primitive would definitely be possible in OpenSCAD.
Main issue is that OpenSCAD would have to render its child object
first to get its
real bounding box and OpenSCAD does not do that for performance
reasons.
Using center() is not clever anyway, because openSCAD would have
to render the object EVERY TIME whereas the user would have to
calculate the translation shift
ONCE, which is much more performant .
On Mon, Sep 23, 2024 at 9:16 AM Peter Kriens via Discuss
<discuss@lists.openscad.org> wrote:
BOSL2 has to work within the limitations of OpenSCAD. Their
support for a generic shape (paths, cubes, prisms, spheres,
cylinders, regions, and vnfs) is quite heroic but it does
indeed fall short since you miss some of the crucial operators
like intersect, diff, etc. on the vnfs.
You probably could make a _composite shape_ that would be able
to postpone the operations until you reify the shape. Since
the original shapes would still be available, you could still
get the combined set of anchors. But this screams for an
Object Oriented approach to not make it explode in complexity
and it feels that is not something OpenSCAD will want to have.
Cheers,
Peter
On 21 Sep 2024, at 15:04, Adrian Mariano <avm4@cornell.edu>
wrote:
You're right that you could use vnf_polyhedron, but in the
example above, the compound object was constructed using
attachment. Suppose magically we had vnf_difference() and
you wanted to construct the example that was posted earlier.
In that example, attachment was used to place the child that
is differenced away. If you use vnf_polyhedron to convert
your two VNFs into geometry then you cannot get a VNF back
out to use the VNF anchors. So at least as things stand,
you'd need to do vnf_difference(vnf1, transform*vnf2) where
transform was computed somehow to be the transform that
performs attachment.
On Sat, Sep 21, 2024 at 2:03 AM Peter Kriens
<peter.kriens@aqute.biz> wrote:
And the VNF calls don't allow you to use attach() so if
you wanted attachment you'd need to simulate it yourself
by applying operators to the VNFs.
That is not true, vnf_polyhedron() is fully attachable.
It calculates the common anchors and can calculate the
vector based on the normals.
On Fri 20 Sep 2024 at 23:53, Adrian Mariano via Discuss
<discuss@lists.openscad.org> wrote:
I would make a stronger statement and say that what
Jonathan is trying to do is not merely impractical
but impossible. He seems to be hoping that by asking
the cube to be centered, the whole object will be
centered, where everything is being computed as
geometry. There is no way BOSL2 could possibly
extract information about the object.
What's impractical is implementing VNF difference.
If we could do that, then we could center objects.
But it would have to be done with VNF generation
commands, not with geometry. And the VNF calls don't
allow you to use attach() so if you wanted attachment
you'd need to simulate it yourself by applying
operators to the VNFs.
On Fri, Sep 20, 2024 at 5:30 PM Jordan Brown via
Discuss <discuss@lists.openscad.org> wrote:
[ I should note that I do not mean in the
slightest to disparage BOSL2. Revar and Adrian
have done amazing work. But there are some
things that are just not practical. ]
On 9/20/2024 10:03 AM, Jonathan Gilbert via
Discuss wrote:
It can definitely *create* that shape object;
and once created, you can definitely center it:
include <BOSL2/std.scad>
xdistribute(spacing=50) {
difference() {
cube(20, center=true);
cylinder(h=11, d1=0, d2=100);
}
diff()
cuboid(20, anchor=CENTER)
attach(TOP, BOTTOM, overlap=10)
tag("remove")
cyl(h=11, d1=0, d2=100);
}
<image.png>
I don't speak BOSL2 well enough to be sure what
you're asking it to do, but neither of those is
centered vertically. (I *think* that you have
centered the cube, rather than centering the
result of the difference.) You can't really see
it from the angle you're showing, but look at
this angle (view from -Y/Front, orthogonal):
<udcR20RffCNm7D8c.png>
The right-hand one is the one you're trying to
center; observe it's at exactly the same position
as the left-hand one, and that there's a lot more
below the XY plane than above it.
Here's what it should look like, from exactly
that same viewpoint:
<50zG2Uy93oI5Xx4o.png>
(Generated using a PR#4478 experimental, using
mechanisms that fully render the object and make
its geometry available to the program.)
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
Passing Geometry from OpenSCAD into user/script space is not difficult.
Question is rather, how the SCAD language can work with the received data.
(and OpenSCAD would have to run a render() run in the middle of the script
already to provide intermediate data)
Template could be
vertices, triangles = my_design.mesh() # Creates a Tuple object with
Vertices and triangles
After the user tweaked the data, it can easily be converted back with
crazy_stufff=polyhedron(vertices, triangles)
On Mon, Sep 23, 2024 at 2:16 PM Chun Kit LAM via Discuss <
discuss@lists.openscad.org> wrote:
I think passing the geometry from objects into userspace is a great way to
allow users to extend openscad features, without having to reinvent the
wheels from the bottom up. With manifold, render is not as expensive as
before (except for minkowski, someone should really write a faster convex
decomposition...). Apart from using the geometry cache, for operations like
translate/scaling/union, you don't really need to render the object to get
its bounding box.
On 23/9/2024 18:54, Adrian Mariano via Discuss wrote:
Of course in native openscad anything is possible, including a center()
operator, if it was desired to implement. But in my experience, wishing
for things to appear in native openscad is a path to disappointment. The
question is what can we do in user space, and right now, implementing a
center operator is impossible. There is a test feature that renders and
passes the geometry from objects into userspace. This would enable a
userspace implementation of centering---and a whole host of great features
as well. Yes, render would run, but I think caching means it would NOT
have to render every time, so it's not as bad as you think.
On Mon, Sep 23, 2024 at 4:07 AM Guenther Sohler via Discuss <
discuss@lists.openscad.org> wrote:
A center() primitive would definitely be possible in OpenSCAD.
Main issue is that OpenSCAD would have to render its child object first
to get its
real bounding box and OpenSCAD does not do that for performance reasons.
Using center() is not clever anyway, because openSCAD would have to
render the object EVERY TIME whereas the user would have to calculate the
translation shift
ONCE, which is much more performant .
On Mon, Sep 23, 2024 at 9:16 AM Peter Kriens via Discuss <
discuss@lists.openscad.org> wrote:
BOSL2 has to work within the limitations of OpenSCAD. Their support for
a generic shape (paths, cubes, prisms, spheres, cylinders, regions, and
vnfs) is quite heroic but it does indeed fall short since you miss some of
the crucial operators like intersect, diff, etc. on the vnfs.
You probably could make a composite shape that would be able to
postpone the operations until you reify the shape. Since the original
shapes would still be available, you could still get the combined set of
anchors. But this screams for an Object Oriented approach to not make it
explode in complexity and it feels that is not something OpenSCAD will want
to have.
Cheers,
Peter
On 21 Sep 2024, at 15:04, Adrian Mariano avm4@cornell.edu wrote:
You're right that you could use vnf_polyhedron, but in the example
above, the compound object was constructed using attachment. Suppose
magically we had vnf_difference() and you wanted to construct the example
that was posted earlier. In that example, attachment was used to place the
child that is differenced away. If you use vnf_polyhedron to convert your
two VNFs into geometry then you cannot get a VNF back out to use the VNF
anchors. So at least as things stand, you'd need to do
vnf_difference(vnf1, transform*vnf2) where transform was computed somehow
to be the transform that performs attachment.
On Sat, Sep 21, 2024 at 2:03 AM Peter Kriens peter.kriens@aqute.biz
wrote:
And the VNF calls don't allow you to use attach() so if you wanted
attachment you'd need to simulate it yourself by applying operators to the
VNFs.
That is not true, vnf_polyhedron() is fully attachable. It calculates
the common anchors and can calculate the vector based on the normals.
On Fri 20 Sep 2024 at 23:53, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
I would make a stronger statement and say that what Jonathan is trying
to do is not merely impractical but impossible. He seems to be hoping that
by asking the cube to be centered, the whole object will be centered, where
everything is being computed as geometry. There is no way BOSL2 could
possibly extract information about the object.
What's impractical is implementing VNF difference. If we could do
that, then we could center objects. But it would have to be done with VNF
generation commands, not with geometry. And the VNF calls don't allow you
to use attach() so if you wanted attachment you'd need to simulate it
yourself by applying operators to the VNFs.
On Fri, Sep 20, 2024 at 5:30 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
[ I should note that I do not mean in the slightest to disparage
BOSL2. Revar and Adrian have done amazing work. But there are some things
that are just not practical. ]
On 9/20/2024 10:03 AM, Jonathan Gilbert via Discuss wrote:
It can definitely create that shape object; and once created, you
can definitely center it:
include <BOSL2/std.scad>
xdistribute(spacing=50) {
difference() {
cube(20, center=true);
cylinder(h=11, d1=0, d2=100);
}
diff()
cuboid(20, anchor=CENTER)
attach(TOP, BOTTOM, overlap=10)
tag("remove")
cyl(h=11, d1=0, d2=100);
}
<image.png>
I don't speak BOSL2 well enough to be sure what you're asking it to
do, but neither of those is centered vertically. (I think that you have
centered the cube, rather than centering the result of the difference.)
You can't really see it from the angle you're showing, but look at this
angle (view from -Y/Front, orthogonal):
<udcR20RffCNm7D8c.png>
The right-hand one is the one you're trying to center; observe it's
at exactly the same position as the left-hand one, and that there's a lot
more below the XY plane than above it.
Here's what it should look like, from exactly that same viewpoint:
<50zG2Uy93oI5Xx4o.png>
(Generated using a PR#4478 experimental, using mechanisms that fully
render the object and make its geometry available to the program.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Sep 23, 2024, at 6:14 AM, Guenther Sohler via Discuss discuss@lists.openscad.org wrote:
Passing Geometry from OpenSCAD into user/script space is not difficult.
Question is rather, how the SCAD language can work with the received data.
There is a proposal at https://github.com/openscad/openscad/wiki/OEP8:-Objects-(dictionaries%3F),-Geometry-as-data,-and-Module-References and a mostly working prototype at PR#4478.
I wonder whether the geometry return can include more topological
information. One of the big slowdowns in doing some algorithms on polygon
soup data is that adjacency needs to be computed, which is not the fastest
operation in OpenSCAD. It seems like the manifold engine already knows
this information and could supply it.
On Mon, Sep 23, 2024 at 12:14 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On Sep 23, 2024, at 6:14 AM, Guenther Sohler via Discuss <
discuss@lists.openscad.org> wrote:
Passing Geometry from OpenSCAD into user/script space is not difficult.
Question is rather, how the SCAD language can work with the received
data.
There is a proposal at
https://github.com/openscad/openscad/wiki/OEP8:-Objects-(dictionaries%3F),-Geometry-as-data,-and-Module-References and
a mostly working prototype at PR#4478.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Adjacency can be calculated very fast. Just store the vertices in a
Oct-Tree and Any Points "near" a given input points can be retrieved in
log2(N) time
Alternatively, for a given point you could look up immediately, which
triangles own this point
All these algorithms are already coded and just need a map to a user
-function.
On Mon, Sep 23, 2024 at 10:39 PM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
I wonder whether the geometry return can include more topological
information. One of the big slowdowns in doing some algorithms on polygon
soup data is that adjacency needs to be computed, which is not the fastest
operation in OpenSCAD. It seems like the manifold engine already knows
this information and could supply it.
On Mon, Sep 23, 2024 at 12:14 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On Sep 23, 2024, at 6:14 AM, Guenther Sohler via Discuss <
discuss@lists.openscad.org> wrote:
Passing Geometry from OpenSCAD into user/script space is not difficult.
Question is rather, how the SCAD language can work with the received
data.
There is a proposal at
https://github.com/openscad/openscad/wiki/OEP8:-Objects-(dictionaries%3F),-Geometry-as-data,-and-Module-References and
a mostly working prototype at PR#4478.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 9/23/2024 1:38 PM, Adrian Mariano via Discuss wrote:
I wonder whether the geometry return can include more topological
information.
I don't know. I grabbed that part of the implementation from a previous
project and did not need to understand how it worked, only that it worked.
The outputs from CGAL and Manifold surely preserve topology. The old
Polyset was just a polyhedron soup but I think it now has indices to
preserve topology.
On Mon, 23 Sept 2024 at 23:27, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 9/23/2024 1:38 PM, Adrian Mariano via Discuss wrote:
I wonder whether the geometry return can include more topological
information.
I don't know. I grabbed that part of the implementation from a previous
project and did not need to understand how it worked, only that it worked.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
The question is not whether they preserve topology but whether they PROVIDE
it. The task of taking a thousand faces and figuring out which ones are
adjacent so you can implement, say, catmull, is not very efficient in
OpenSCAD, and my guess is that OpenSCAD already KNOWS this information, so
forcing me to recompute it in userspace is inefficient.
On Mon, Sep 23, 2024 at 6:43 PM nop head via Discuss <
discuss@lists.openscad.org> wrote:
The outputs from CGAL and Manifold surely preserve topology. The old
Polyset was just a polyhedron soup but I think it now has indices to
preserve topology.
On Mon, 23 Sept 2024 at 23:27, Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 9/23/2024 1:38 PM, Adrian Mariano via Discuss wrote:
I wonder whether the geometry return can include more topological
information.
I don't know. I grabbed that part of the implementation from a previous
project and did not need to understand how it worked, only that it worked.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org