Bosjes Chapel

In my course, we have the task of modelling something architectural using kangaroo.
I’ve decided on the Bosjes Chapel and constructed the anchor points, but now I’m stuck. I’ve tried a few things, but nothing has led me to my goal.
Maybe I’m on the wrong track and it’s not realisable at all
Does anyone have any ideas?

Skript Bosjes (40.0 KB)

I see no reason to use Kangaroo for this? Or Mesh Surface either, as you can do this with Network Surface:

Bosjes (16.9 KB)

I did not play with anything earlier in your code to shape the surface, other than what you see in the image. Looks like you also will want to thicken the surface in a non-uniform way? Perhaps by creating a second surface and lofting between the two to get an edge surface.

Looks good! :+1:

Looking at this further, I can see that the four corners of this roof should be rounded (flattened?) instead of points in the sky. I have ideas about how to do that using NURBS curves instead of Interpolate but if you must do a Kangaroo project, I don’t think this chapel is a good choice. So I won’t bother.

I agree with Joseph that this building is not one where it makes sense to use Kangaroo.

If the task you have been given is to model something using Kangaroo, then some tensile / catenary / gridshell / inflatable structure would be better. For these types of structures the form finding process is a key part of creating the geometry.

1 Like

This got more than a little crazy and doesn’t quite handle the corners as I had hoped. Distractions…
But as I said, this isn’t a good choice anyway if you must do a Kangaroo project.

Bosjes (25.7 KB)

1 Like

It’s interesting to see how similar the final shape is by Lofting just the Nurbs curves:


Again, this geometry is perfectly suited for NURBS curves and surfaces. Not appropriate for Kangaroo.

Having said that, it is interesting enough that I spent more time on it, getting the corners closer to the shape in images of the structure and scaling dimensions based on this image from a PDF file:

My notes using pixel dimensions:

front: 426 X 132
side: 257 X 132
39 pixels = height of man

426 / 257 = 1.657587548638132
257 / 426 = 0.6032863849765258

426 / 39 = 10.923 * 6 feet = 65.538

132 / 39 = 3.384615384615385 * 6 feet = 20.3
57 / 132 = 0.4318181818181818 * 20.3 = 8.766

Scaled by a man in that image assumed to be six feet tall (39 pixels high). The horizontal dimensions in X and Y are calculated exactly. The vertical dimensions required adjusting Z sliders based on visual comparisons because of the NURBS curves, which don’t touch middle points.

Bosjes (30.2 KB)

It’s not perfect but it’s close; with more work it could be.


Here’s one way you could do it simply with a scripting component. (12.1 KB)


If you consider scripting to be simple. And don’t care about dimensions?
And are happy with a mesh output (or surface from points).

But yeah, it’s interesting.

1 Like

Ha. Yep, I guess it does come with some caveats.

This script and MeshCageMorph… :sunglasses:

Also, it requires R8. I had two unpleasant experiences with R8 this morning that put me in a bad mood.

I can easily understand that using new R8 features makes a GH file incompatible with R7. But who decided it was OK to break compatibility over Area? Does it occur to anyone that a change to R7 could recognize the R8 Area component and substitute the R7 version?

Maybe the same goes for this R8 Script component? Or is that a bridge too far?

I’ve also seen many failures of R8 in common tasks like not treating an extrusion as a brep, which I see that you have now fixed. It just seems very late in the R8 release process to be finding stuff like this.