Document how to use BOSL2 Attachable

[epigramengineer]

One of the core constructs of BOSL2 is making your own attachable objects, see https://github.com/revarbat/BOSL2/wiki/Tutorial-Attachments#making-attachables.

This doesn't seem possible in SolidPython as there is no support for constructing a module as far as I can tell without just writing the scad code directly. attachable in BOSL2 is what lets you create custom attachment points with named_anchor. I'd like to be able to define a shape with different attachment points, and construct multiple of them and then add children attached to those various points on it.

Am I thinking about the paradigm incorrectly? How should I achieve this using SolidPython?

[jeff-dh]

To be honest, I haven't look that deep into it (BOSL2) yet.

I just had a brief look at the corresponding part of the BOSL2 docs and for now I have to disappoint you, it's not supported yet.

One issue is that SolidPyton / expSolid has no equivalent to modules -- but I did some testing (for a different issue) with adding kind of module support to expSolid.

I'll think about it and maybe I'll come up with something.

[jeff-dh]

Check this branch out:

https://github.com/jeff-dh/SolidPython/tree/exportResultAsModule

Example:

https://github.com/jeff-dh/SolidPython/blob/exportResultAsModule/solid/examples/18-modules-and-children-bosl2-attachables.py

It's one of the examples from the docs.

Default values for parameters are not working yet..... maybe more, I don't know, but as far as I understand it it's basicaly working.

If you have any opinions on it or if you have any (further) issues with it, let me know.

[jeff-dh]

btw: there are some restraints that come along with it. The parameters that get passed into the function (~> module) are not regular python values anymore. They are wrapped as "ScadValues". These values are not known at python runtime (since they are scad values / variables that only get assigned / evaluated at OpenSCAD runtime).

The result is, that you can't evaluate them at python runtime! You can use them to pass them as parameters or even do basic mathematical operations on them and then pass them on, but you can't evaluate them. This means you can't use them for example in an if-statement or a for-statement as expression.

You'll trip over it and you're gonna get an error when trying to do it ;)

[jeff-dh]

Default parameters are working now.

I would appreciate it if you could check whether everything you want to do is possible with that solution.

[jeff-dh]

I'm wondering whether we really need to wrap all that stuff into an openscad module, because with that we get the restrictions on the parameters which will limit the usability of it.

There's something brewing in my head about another solution that might be more powerful and more (Solid)Pythonic instead of the exportResultAsModule hack. Using openscad modules with SolidPython is never gonna work out well because of the parameters which is a technical boundary....

[jeff-dh]

Actually we don't need to wrapp it into a module.

This works just fine (even though it's a little awkward) but with some syntactic sugar on the (Solid)Python side this could provide a solution which would make this feature available in a pure (Solid)Pythonic way.

from solid.extensions.bosl2 import *

def cubic_barbell(s, anchor=CENTER, spin=0, orient=UP):
    return attachable(anchor,spin,orient, size=[s*3,s,s]) (
        union() (
            xcopies(2*s)(cube(s, center=True)),
            xcyl(h=2*s, d=s/4)
        ),
        union()(
            attach(TOP)(cube(50)),
            attach(LEFT)(sphere(50)),
            show_anchors(30)
            )
    )

print(cubic_barbell(100).as_scad())

I'll probably spend some time on it in the next couple of days.

[jeff-dh]

I found some easy & short solution for the issue. It's a ~10 line "hack" in die bosl2 extension that uses the idea I posted above.

The result is as follows and I assume meets all requirements. Give it a try.

from solid.extensions.bosl2 import *

def cubic_barbell(s=100, anchor=CENTER, spin=0, orient=UP):
    return attachable(anchor,spin,orient, size=[s*3,s,s]) (
        union() (
            xcopies(2*s)(cube(s, center=True)),
            xcyl(h=2*s, d=s/4)
        )
    )

cc = cubic_barbell(100)(
        cube(50).attach(TOP),
        sphere(50).attach(LEFT),
        show_anchors(30)
    )

print(cc)

If you have any issues let me know.

[jeff-dh]

Btw: it's already -- and only -- in the (main) exp_solid branch.

[jeff-dh]

I close this issues.

The requested documentation is here: https://github.com/jeff-dh/SolidPython/blob/exp_solid/solid/examples/07-libs-bosl2-attachable.py

[epigramengineer]

Thanks @jeff-dh! (Sorry for the delayed response, not very active right now). Much appreciated for the investigation, going to start using it right away! :D

[jeff-dh]

I would appreciate feedback about any issues / pitfalls / nice-to-haves concerning it. (I couldn't really get into that work flow and thus couldn't test it excessively)

[epigramengineer]

Your example doesn't quite work.

from solid.extensions.bosl2 import *

def cubic_barbell(s=100, anchor=CENTER, spin=0, orient=UP):
    return attachable(anchor,spin,orient, size=[s*3,s,s]) (
        union() (
            xcopies(2*s)(cube(s, center=True)),
            xcyl(h=2*s, d=s/4)
        )
    )

cc = cubic_barbell(100)(
        cube(50).attach(TOP),
        sphere(50).attach(LEFT),
        show_anchors(30)
    )

print(cc)

cc needs to be:

cc = cubic_barbell(100)( union() (
        cube(50).attach(TOP),
        sphere(50).attach(LEFT),
        show_anchors(30)
    ))

As attachable takes exactly two children. One ergonomic improvement here could be at build time:

1. If you have zero things to attach attachable(...)(obj) then add an empty child
2. If you have more than one thing to attach attachable(...)(obj)(child1, child2) then union those children
3. If you've called attachable(...)(obj1, obj2) then error as you've provided too many objects to attach to.

So attachable would have the be a function of parameters => attach_object => children_to_attach

That's a thought. Another option would be to not encourage the use of attachable as it doesn't quite line up with the pythonic way of doing things, and instead recommend that users create optional kwarg parameters (list of objects) for the different named attachment points, and in the user defined helper function use those kwargs to create the attachments. I'm not sure I've dug in enough usage to understand which is better yet.

[epigramengineer]

Sorry, when I updated the git repo reference I didn't realize it had changed the module to solid2.

[jeff-dh]

You're right about the union of attachables, buuuuuut ;) I added an overwritten version of attachable.add in the bosl2 extensions and it handles exactly that case. At least it's supposed to do. It should even be possible to "call the attachable" multiple times: ```python cc = cubic_barbell(100)( cube(50).attach(TOP), sphere(50).attach(LEFT), show_anchors(30) ) cc(cube(27).attach(BOTTOM)) ``` prints out: ``` attachable(anchor = CENTER, orient = UP, size = [300, 100, 100], spin = 0) { union() { xcopies(spacing = 200) { cube(center = true, size = 100); } xcyl(d = 25.0000000000, h = 200); } union() { attach(from = TOP) { cube(size = 50); } attach(from = LEFT) { sphere(r = 50); } show_anchors(s = 30); attach(from = BOTTOM) { cube(size = 27); } } } ``` alternatively you could also do something like this: ```python cc.add(cube(72).attach(RIGHT)) ``` All the same and the add function (which get's called under the hood if you "pass children") handles the union issue. I agree with you with your thoughts about what is actually a proper (solid)pythonic way. I'm also not deep enough into it to have real idea about it. But if anyone has, I'm interested in it.