The BOSL2 library does support general shapes with the VNF (Vertices'N'Faces structure).

A vnf can be constructed through a function. BOSL2 has functions for all the base modules and many (MANY!) more. You can reify a vnf with the vnf_polyhedron() function.

vnf = sphere(20); 
vnf_polyhedron(vnf);

you can still use the vnf to attach properly.

radius = 20;
cyl(r=radius,l=40) 
	attach([TOP,BOTTOM],BOTTOM,shiftout=-radius) 
		vnf_polyhedron(vnf);

You can make arbitrary complex vnf's:

vnf = join_prism( 
rect(10,rounding=2), 
base="plane", aux="sphere", 
aux_r=20, 
aux_T=translate([0,0,30], 
fillet=5 ), overlap=0);
vnf_polyhedron(vnf);    

And the attach still basically works.

length = 30;
radius = 20;

vnf = join_prism( 
rect(10,rounding=2), 
base="plane", 
fillet=5,
    aux="sphere", aux_r=radius, aux_T=translate([0,0,length]));

cyl(r=radius,l=5,rounding=2) 
attach(TOP) {
       vnf_polyhedron(vnf);
       up(length) sphere(radius);
    }

In this case we need to do an up(length) to position the ball because the vnf has a top and bottom, but it lacks an anchor for the position where the sphere should attach. Unfortunately, we lose the custom anchors that the join_prism() provides. In this case it has an anchor named "end" that represents the perfect position for the shape of the aux side (BOTTOM,LEFT, etc.).

length = 30;
radius = 20;
cyl(r=radius,l=5,rounding1=-2, rounding2=2) 
  attach(TOP) {
  join_prism( 
     rect(10,rounding=2), 
     base="plane", 
 fillet=5, 
     aux="sphere", aux_r=radius, aux_T=translate([0,0,length]))
     attach("end", BOTTOM) sphere(radius);

Anyway, to make any shape you define yourself work in this scheme is a lot easier than I thought. See the attach.scad#attachable() function. I now routinely do this for any component and generally define custom anchors. I cannot tout the advantages of this model enough. No more complex calculations where the  part really goes.

As said, I probably would've left OpenSCAD if it wasn't for this relative addressing and support for shapes as variables. It seems to me a prime candidate to include in the base functionality.

Regards,

Peter

[ Pardon for the dup, sent from wrong address. ]

On 9/20/2024 3:16 AM, Peter Kriens via Discuss wrote:

I don't believe that BOSL2 can do differences, intersections, and unions
of VNFs.  (Or hull, projection, minkowski.)

As an example, I don't believe it can center this object:

difference() {
    cube(20, center=true);
    cylinder(h=11, d1=0, d2=100);
}

It can definitely create that shape object; and once created, you can
definitely center it:

include <BOSL2/std.scad>

[image: image.png]

On Fri, Sep 20, 2024 at 9:58 AM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

--

• Jon Gilbert
  jong@jong.org / jgilbertsjc@gmail.com

Jordan is correct. BOSL2 cannot do very many operations on vnfs and
centering or attachment will only work if you can create a vnf or if the
shape is directly produced by a BOSL2 command. Operations like difference
are prohibitively expensive in user space. If the feature to extract
geometry data ever appears this will change.

I think that reading openscad code to learn how to push openscad limits
makes sense but if you want to learn how to do something in general it’s
not the best idea since it generally imposes limits that prevent
implementation of the best algorithms.

On Fri, Sep 20, 2024 at 13:05 Jonathan Gilbert 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:

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):

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:

(Generated using a PR#4478 experimental, using mechanisms that fully
render the object and make its geometry available to the program.)

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:

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:

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:

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

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: