Aligning sub-shapes to terrain

[Anonymous User]

Original User: nicolaisteino2

I am working on a script which simulates Utzon's famous Fredensborg houses http://bit.ly/15EuuaA which are chains of patio houses which align to a sloping terrain.

I have two problems:

1. I can't figure out how to correctly align the individual houses within the scheme �?? which is generated from a single lot-shape �?? to the terrain. As it shows in the pics, the houses seem to sink into the lot shape, and even more so into the terrain. It seems on the one hand, that the lot-shape does not recognize local hills and depressions within the area of the lot-shape. Furthermore, the sub-shapes of the buildings don't seem to align correctly to the lot-shape.

Is there a way to correct this?

2. As it can be seen in the reference photos, the footprint of the houses is an L-shape. The roofs are shed roofs which incline inward. This means that there is a roof valley in the knee of the L-shape.

Is there a neat way �?? or any way at all �?? to generate this type of roof for this type of footprint?

Regards,

Nic

--

/**
* File:    utzon_rule.cga
* Created: 25 Jun 2013 21:09:22 GMT
* Author:  nic
*/

version "2012.1"

attr width01 = 75
attr width02 = width01
attr width03 = 22
attr bldgH = 3.5
attr bldgW01 = 9
attr bldgW02 = 7
attr wallW = 0.35
attr wallH = 2
attr pathW = 2
attr roofA = 25
attr footprintShift = width03/4
attr outsideWidth = (width01-width03)*0.50
@range(-90,90)
attr rotation = 0
attr randomGrey = listRandom("#ffffff;#0000ff;#ff00ff;#00ffff;#000000")

Lot --> rotateScope(0, rotation, 0) split(x) { ~width01 : Left | ~width02 : Right }*
Left --> innerRect split(z) { ~width03+footprintShift : Strip01 | { ~width03 : Strip02 }* }
Right --> innerRect split(z) { { ~width03 : Strip02 }* | ~width03+footprintShift : Strip03 }
Strip01 --> case scope.sx < width03*2 : NIL
   else : split(x) { width03 : Strip01Split01 | width03 : Strip01Split02 | ~1 : NIL }
Strip02 --> case scope.sx < width03*2 : NIL
   else : split(x) { outsideWidth+rand(-footprintShift, footprintShift) : NIL | width03 : Plot }
Strip03 --> case scope.sx < width03*2 : NIL
   else : split(x) { width03 : Strip01Split02 | width03 : Strip01Split01 | ~1 : NIL }
Strip01Split01 --> split(z) { width03 : Plot | ~1 : NIL }
Strip01Split02 --> rotateScope(0, 180, 0) Strip01Split01

Plot --> color(listRandom("#cccccc;#0000ff;#ff00ff;#00ffff;#333333")) shapeL(bldgW01, bldgW02) { shape : Footprint | remainder: Exterior }
Exterior --> rotateScope(0,180,0) shapeL(wallW, wallW) { shape : Wall | remainder: NIL }
Footprint --> alignScopeToAxes(y) s('1,0,'1) extrude(world.y, bldgH) Envelope
Envelope --> comp(f) { top : Top | side : Side. }
Top --> convexify() roofShed(roofA)
Wall --> alignScopeToAxes(y) s('1,0,'1) extrude(world.y, wallH)

[Anonymous User]

Original User: matthiasbuehler

Hi !

Since the layout is so specific, I'd not try to recreate the building distribution in CGA, but place all footprints manually ( 1 footprint shape per building, which is aligned to the terrain.

This will make things a lot easier. Not everything in CE needs to be done procedurally .. 🙂

Also, align the terrain back to the shapes !

Let me know if this helps !

Matt

[NicolaiSteinø]

Thank you for your reply!

I realize that I did not explain myself well enough:

My goal is not to generate that particular housing scheme. On the contrary, I wan't to parametrically adapt the logic of the housing scheme to different sites with different sizes and terrains. Therefore, the very point for me is to use rules rather than generating dead geometry.

As I take my point of departure in the real world, aligning the terrain back to the shapes would mean to use heavy machinery to move around a lot of soil. Also, the very point of the Frendensborg houses is that they align to the terrain as it is. This is also an important point for me in re-using the "code" of this development at different sites.

Finally, as I work a lot with site design (for real sites) my question �?? whether there is a way to align sub-shapes to the terrain �?? is still central to my work.

Hopefully this explains my needs better.

And, if you have a suggestion to my second question, I'd be very grateful:


[INDENT]2. As it can be seen in the reference photos, the footprint of the houses is an L-shape. The roofs are shed roofs which incline inward. This means that there is a roof valley in the knee of the L-shape.

Is there a neat way �?? or any way at all �?? to generate this type of roof for this type of footprint?
[/INDENT]


Regards,

Nic

[Anonymous User]

Original User: matthiasbuehler

Hi,

Ah I see. Now, all's clear.


For the 'building distribution, I'd use dynamic streets. Using basically a similar approach as if you'd have to place a line of trees procedurally, I usually do that with streets too. 😉 Makes sense ?

E.g. make a street with sidewalk width 0 and on the street itself, write something like :

attr myOrientation = 360

attr buildingDepth = 15
attr buildingWidth = 10

Street -->
    alignScopeToAxes() // orient to world grid
    rotateScope(0,myOrientation, 0) //rotate my scope to adjust the building orientation
    split(z) {buildingDepth : Stripe}*

Stripe -->
    s(buildingWidth, 1,'1)
    center(xz)    
    i("builtin:cube")
    comp(f) {bottom : reverseNormals Footprint | all : NIL}

Footprint -->
    X.

I did not test the code, but this should cut up your street shape in bits on which you then can place building footprints.

Concerning aligning the footprint to the terrain:
This is currently not possible direclty in CGA since a sampling operation is missing. Only the pivot of the start shape can sample the terrain ONCE.
Thus once the footprints are placed correctly in their position, you need to convert them to static shapes and use the 'align Shapes to Terrain' function. [this can also be done in Python if you need faster design iteration times.]


Concerning the roof, I currently have no solution in my mind. Let me think about this and try the rest for now.

Ok ?

Matt

[NicolaiSteinø]

Hi Matt,

The street approach is interesting �?? I hadn't thought about that. I'll try it out, compare it to the static shape approach, and get back with the results..

Thanx,

Nic