Attachable 2

[pkriens]

An attachable component calls attachable and ensures that the first child is the render module and the second child calls the children of the component.

module component() {
  attachable(geom=...) {
      ... render
      ... call children
  }
}

The attachable() module then uses pure magic to position the shape with a proper transformation, sets up the variables, and calls child(0) to render the shape. After this, it sets the given geometry as the current geometry and calls the remaining children.

Recently Adrian introduced parts. Parts are descriptors for a part of a component. Children of the component can get these descriptors by name and make them current with attach_part(name). The archetypal example is the "inside" of a tube. This is very useful when you build components that consists of other components.

For example, I have the following composite that consists of 3 other components.

module composite(size=[10,10,10], anchor, orient, spin) {   
    parts = [
        define_part("top", attach_geom(size/3), T=up(size.z/3)),
        define_part("middle", attach_geom(d=size.x,h=size.z/3)),
        define_part("bot", attach_geom(d=size.x/2,h=size.z/3), T=down(size.z/3)),
    ];
    attachable( size = size, parts=parts, anchor=anchor, orient=orient, spin=spin ){
        cyl(d=size.x, h = size.z/3) {
            attach(TOP,BOT) cuboid(size/3);
            attach(BOT,TOP) tube(od=size.x/2, wall=1,h=size.z/3);
        }
        ;
    
        children();
    }
}
composite(anchor=BOT) 
attach_part("bot") 
attach( LEFT,BOT) cuboid(2);

However, I need to synchronize the part definitions with the render functions. Worse, the offsets that are so wonderfully calculated by attach() during render I must now repeat without support.

I wonder if we could rearrange attachable like this:

module composite2(size=[10,10,10], anchor, orient, spin) {    
    attachable( size = size, parts=parts, anchor=anchor, orient=orient, spin=spin ){
        cyl(d=size.x, h = size.z/3) let(middle=parent())
        attach(TOP,BOT) cuboid(size/3) let(top=parent())
        restore(middle)
        attach(BOT,TOP) tube(od=size.x/2, wall=1,h=size.z/3) let(bot=parent())
        with_parts( 
            [ define_part("middle", middle),
            define_part("top", top),
            define_part("bot", bot)] ) children();
        ;
        union();
    }
}

Being to call the children while the stack contains all the context would simplify (I think) a lot of things. It would save an enormous amount of redundancy and make attachable much more attractive to use.

The only missing sore is that the attachable still needs the geometry so I still have to calculate the bounding box. However, since attachable needs to position child 0, it seems inevitable.

I might be missing something (again) that makes it impossible but I think it would clean up my code a lot. Actually, it would make me basically turn every component into an attachable!

And when I am here ... a minor issues. When your restore a descriptor, the parts are no longer there. It would be convenient if the parts were connected to the descriptor. So if you restore a descriptor, the parts of that descriptor are current.

[adrianVmariano]

So you're wanting to use the descriptions associated with parts of the model to create the parts data structure. It seems like a nice goal if it can be realized.

It is actually crucial to the functionality of attachables that the attachable object itself is a separate child from the children. In other words, the model of attachable() { render(); children(); } is fundamental. For example, application of color with recolor() works because color can be applied separately to the render() part and the children() part. So your vision would have to be created by changing only the render() portion. But then how can the information about parts be propagated? It needs to be available to the children, so you can't compute it in the render() portion because that's a different leaf on the tree.

It should be easy to add parts to descriptions.