Union of vnf's

[pkriens]

To round an arbitrary path I use path_sweep to create a vnf with the rounding mask and the skin or sweep to extrude the path into the same height as the rounding. I assumed I would get the union if I gave these vnf's to the polyhedron module with a list. This actually seemed to work:

but then with F6:

When I use a union() { vnf_polyhedron(vnf0); vnf_polyhedron(vnf1); } it works fine.

The problem is that I'd like to have the proper union of these vnf's as a single vnf so I can pass it to other functions and modules.

Is there such a function? Is this the right approach?

include <lib/BOSL2/std.scad>
include <lib/BOSL2/fnliterals.scad>


path = turtle([
    "move", 5,
    "arcleft", 10,
    "move", 20,
    "arcright", 10,
    "move", 40,
    "arcright", 10,
    "move", 20,
    "arcleft", 10,
    "move", 5
    ]);

vnf0 = path_sweep(mask2d_roundover(h=3), path);
vnf1 = sweep(path,[up(0),up(3)]);


diff() prismoid( [200,200], [100,100], 80 )  {
    attach( FRONT, BOTTOM,align=BOTTOM, inside=true, shiftout=0.2) union() { 
        vnf_polyhedron(vnf0);
        vnf_polyhedron(vnf1);
    }
}
xmove(300) diff() prismoid( [200,200], [100,100], 80 )  {
    attach( FRONT, BOTTOM,align=BOTTOM, inside=true, shiftout=0.2)
        vnf_polyhedron([vnf0,vnf1]);
}
        

[revarbat]

I'm afraid that 3D VNF unioning has not as yet been implemented in BOSL2. It's a difficult and slow operation to implement in the OpenSCAD language.

[pkriens]

thanks for the quick answer. Sorry to hear this is not supported but I guess I understand.

I am struggling a bit. I have 50 years of software experience and I like to modularize my code. I love the BOSL2 model where you have a function for each shape and most operations. This allows me to create components that I can pass as parameters. Added advantage is that they all have proper names which can increase the readability a lot. The base OpenSCAD model feels 'very side effectivy' despite that it is a functional language.

Would it be an idea to make the VNF you support richer, i.e. add a type code and allow it to represent a list of builtin VNFs plus an operation like diff, 'hull`? At render time you could then use the proper OpenSCAD operator.

Anyway, thanks for the very impressive library.

[adrianVmariano]

What you're suggesting sounds like re-writing modules through VNFs. In other words, to make a super-VNF data structures that is a boolean operator tree of VNFs. We can already do that by writing a module, and it doesn't seem to offer any obvious advantage over using the existing module method. Is it possible that you're not aware that you can have modules for each shape? That approach will enable code modularity.

[pkriens]

I am still mentally struggling with this ... so take what I say with a grain of salt.

The modules are a solution to insert a transformation matrix ahead of running its children. The shape that is generated is basically caused by the side effects of the modules.

  scale([2,2,2]) cube(3);

The scale module will set a new "current" transformation that doubles the x,y, and z after which it calls its children. It is an interesting way to do this although it took me some time to 'get' it.

One of the really nice things of BOSL2 is that it can do this:

vnf = cube(3);
vnfx2=scale([2,2,2], vnf);

So instead of committing to an output, I can transform a shape before I make render it. For example, since I can get the bounding box of each VNF, I can take a list of VNFs and distribute them evenly in a given space. This cannot be done with he module approach since it cannot query the bounding box (or anything else) of the shape that is generated by its children.

Although the concept of children is interesting, it is kind of awkward to use a programmer. For example, I wrote a module that inserted a shape with holes into a solid table. If you do a difference, you lose the holes, if you do an intersect, you just have the original shape. The solution was to pass the solid as the first child, and then the other children as the insertables with holes.

module insert() {
      difference() {
          children(0);
          hull() { for (i=[1:1:$children-1] children(i); }
      }
      for (i=[1:1:$children-1] children(i);
}

Clearly the first child needs to be treated special, it would be cleaner if this could be parameterized with a proper name and default.

I also had the problem that I needed to create a tableau with different inserts in rows and columns. There were about 10 different insert types. In the end I passed the modules that created the shapes as children and then passed an array with indexes that specified the layout. Works, but feels very indirect.

So my issues with the module concept are that

• it basically uses side effects in a functional environment, and
• that I cannot query the shapes to make generic modules/functions that adapt to the shapes given, and
• cannot easily parameterize shapes by name but need to use indexes.

Then again, a lot of this is moot. The BOSL2 library is quite incredible but the VNF supports makes it painfully slow. If this was going to be an idea, it would probably need native support.

thanks for the feedback.

[adrianVmariano]

Yes, it's true that you can modify the vnf with the scale operation as you show above to produce a new vnf. You say, "So instead of committing to an output, I can transform a shape before I make render it." But you don't really say why this is a useful thing, other than the business about extracting bounding boxes from the vnf, which is a weak advantage. Note that precisely the same thing can be done with modules:

module vnf() cube(3);
module vnfx2() scale(2) vnf();

I do not understand why you think you can only parameterize things by indices. You can parameterize however you want. Use a cascading if statement to check various string options, or use search() on an array of names to get an index and then use that to index. Modules in the BOSL2 library often use scalars, vectors, text strings, booleans, or a combination of all four of these things to define the shape.

Arguably extracting bounding boxes from a vnf is not a very interesting capability, nor generally useful. I don't think I have made any models where I needed to distribute a bunch of objects of unknown size over an area. At least for the 3d printing I do, that's not a typical situation. That said, the inability to extract information from OpenSCAD geometry is a major frustration. You can work around this a bit. More on that below.

I do not understand what you mean about modules "using side effects in a functional environment". First of all, most OpenSCAD users do all of their work entirely with modules. Arguably modules are the dominant and defining feature of the OpenSCAD environment. Furthermore, modules operate in a functional way. It's just that there are two mechanisms for passing parameters, one for variables and one for geometry.

Side effects do exist, but it doesn't sound like you're aware of them or are using them. What I would call side effects are the variables that start with a $ that you can use in a module to change the behavior of children. I think you need to read the BOSL2 Attachments Tutorial to gain some insight into a way of working around geometry not revealing information: the module can know the information, since it made the geometry, and pass it through $ variables to children.

The methods described in that tutorial should enable you to work around the problem you described of wanting to combine an object with a second object that has a hole. https://github.com/BelfrySCAD/BOSL2/wiki/Tutorial-Attachments

[pkriens]

Thanks for the feedback. Maybe it is just a matter of different perspectives/values based on experience? I am a veteran software developer and I just find it very hard to live in an environment without reflection/introspection. My experience is that you can reduce the size of the code enormously with generic functions that can adapt to the parameters they get.

And I am not mistaken this seems the way BOSL2 is developing? Most shapes and transformations are available as functions.

A few days ago the following functions were added:

vnf_boundary
vnf_offset

With these new functions, you can stroke the boundary of a vnf using these introspective functions.

include <BOSL2/std.scad>
include <BOSL2/beziers.scad>
patch = [
     // u=0,v=0                                         u=1,v=0
     [[-50,-50,  0], [-16,-50,  20], [ 16,-50, -20], [50,-50,  0]],
     [[-50,-16, 20], [-16,-16,  20], [ 16,-16, -20], [50,-16, 20]],
     [[-50, 16, 20], [-16, 16, -20], [ 16, 16,  20], [50, 16, 20]],
     [[-50, 50,  0], [-16, 50, -20], [ 16, 50,  20], [50, 50,  0]],
     // u=0,v=1                                         u=1,v=1
];
bezvnf = bezier_vnf(patch);
boundary = vnf_boundary(bezvnf);
vnf_polyhedron(bezvnf);
stroke(boundary,color="green");

A key example why the VNFs are so useful is for example for attachable(). I like to define anchors for my custom shape so I make a scaffold that has roughly the outside shaped and has all the anchors for the inner spaces and the objects inside those spaces. For example, for a shape that goes from a circle to a square and needs to be stackable:

module squaringthecircle(size,height) {
    vnf = skin( [circle(d=size), square(size,center=true)], z=[-height/2,height/2], slices = 10,method="reindex");
    
    r = size/2*sin(45);
    attachable(vnf=vnf, anchors=[
            named_anchor("l-f",[-r,-r,height/2],orient=LEFT+FRONT,spin=135),
            named_anchor("l-b",[-r,r,height/2],orient=LEFT+BACK,spin=45),
            named_anchor("r-f",[r,-r,height/2],orient=RIGHT+FRONT,spin=-135),
            named_anchor("r-b",[r,r,height/2],orient=RIGHT+BACK,spin=-45),
        ]) {
        vnf_polyhedron(vnf);
        children();
    }
}

squaringthecircle(10,10) {
    attach(["l-f","r-f", "l-b","r-b"],LEFT) cyl(d=1.5,h=1,rounding=0.4);
    attach(TOP,BOTTOM) color("grey") squaringthecircle(10,10); 
}

Very impressively, BOSL2 can accurately calculate the anchor vectors from the VNF, this is a clear example of the reflection that the library allows. Last, but not least, since you can pass functions as a parameter, you can pass functions that decorate shapes deep down in the call tree.

• About the side effects, the way the CGAL data structure is a global and is modified through side effects; They try to avoid those as the plague in functional languages.
• could it be that if you had a distribute() function, you might find the use for it? :-)
• I tried to use the tags with the attachment but kept running interference with deeper tags. I can probably work it out but it took too much effort what I could also get in this way. Then again, I did not study it too deeply.

But as I said, it seems moot. Although BOSL2 comes quite far, the speed penalty is prohibitive. I am, however, duly impressed with what is there. It is very enticing.

[adrianVmariano]

There's a guy who posts to the forum who uses Python to do all the geometry and just uses OpenSCAD as a rendering engine. Perhaps this approach would appeal to you.

I agree that it would be nice to be able to get information out of geometry.

I'm not sure I understand how constructing the geometry is a "side effect". What makes it "side"? It's the effect. The OpenSCAD file represents the CGAL data structure----that's the purpose of the file. So how is it a "side" effect? The issue of getting information out of geometry is fundamental. Things like positioning objects could be done without needing the VNF if we could extract object size information from the geometry. I think actually the reason that you cannot do this is that extracting that information would be a side effect. That is, you have to render() the geometry to know what it is to be able to extract the geometry data.

With tags you probably need to create a tag scope to prevent tags at multiple levels from interfering.

I use the distribute modules (xdistribute, ydistribute, zdistribute) fairly often----but only for the purpose of laying out a set of example objects in the BOSL2 manual, not for any real modeling purpose.

When you talk about "the speed penalty" what are you referring to? Is there some existing BOSL2 operation that is problematic?

[pkriens]

The basic definition of functional is that the functions are pure mathematical functions, e.g. a mapping between values. A good test is always if you could have multiple independent CGAL trees? Nope, there is only one. This makes it a global. There are some builtin modules that modify this singleton. This is not really the functional model but I am also a bit pedantic ... OpenSCAD works very well. Its just that I see BOSL2 providing more and more functions moving in this direction. I am original a hardware guy and became an expert in Java modularity. In my experience the environment could support much more reusability functions when it moves into a the pure functional approach. I expect that the author of the library is thinking along these lines. Unfortunately, the lack of object oriented structures makes it quite complex.

That is, you have to render() the geometry to know what it is to be able to extract the geometry data.

That is the approach I saw in the issues on OpenSCAD. I think this is a quirk of the way OpenSCAD is currently handled in the software. The VNF structure is a full polyhedron, it models any 3D shape. If there were (fast) methods for difference, hull, and intersection, you could do everything with the VNF. I can't see the reason why you would have to 'render' it before you could reflect on the shape information?

The CGAL library is also available in Java and that is where my experience lies. My hands are itching but I promised myself to not get deviated. I have a design to make that needs to be finished first. But ... :-)

The speed is mostly the VNF operations. The sweep and skin methods are slow and any function that returns a shape must return a VNF.

I've seen the solutions on the tags and I might look further but main concern was that choices deep down in the call tree would affect things higher up in the call tree. Scoping does help but not sure I want to manually manage it?

[adrianVmariano]

The CGAL tree is the output of an OpenSCAD program. Modules are a mapping from inputs to the CGAL tree. Yes, it's global. Does that mean the relationship is not functional? (Note also that OpenSCAD is moving towards Manifold instead of CGAL. Manifold is a lot faster.)

In terms of BOSL2 design, it's actually frustrating that we are forced to make functions instead of being able to provide better integrated modules. This is due to the inaccessibility of the geometry. It means a division in approach depending on whether you have geometry or data available.

However, modules perfectly allow for reusable "functions". I do not understand how using functions running on VNFs is different in any practical sense if we posit modules that can see inside the geometry. (And for VNFs to work we need to make a similar assumption, that we have access to geometric operations, so neither thing is presently possible.) I believe that the OpenSCAD developers see modules as the central feature of OpenSCAD and are likely to enable us to make better modules rather than making it easier to write code that works on VNFs. (A few years ago Revar tried to get them to include code for applying 2d union/intersection etc to paths and that has not been accepted.)

The reason that you have to render() to get shape information out of geometry in OpenSCAD is because the shape information doesn't exist until you do so. It is created during the rendering process. Until render is run there's just a tree of commands.

The skin and sweep methods should not be particularly slow (except in the case of skin with the O(n^3) vertex alignment method). What do you mean by slow? I'm also not sure what you mean when you say "any function that returns a shape must return a VNF" like this is a limitation or disadvantage somehow?

For tags you can declare a local scope by doing tag_scope(){ ... } in each module and hopefully not have to think about it across levels after doing so. At least, that's how it's supposed to work. Note that it's impossible for things deep in the call tree to affect things above, because information only flows downward.

[pkriens]

because information only flows downward

I think that is the crux ... :-)

I think we're not that far of.