Latest Contributions by NicolaiSteinø

Hmm, tangent, of course – I knew something wasn't right… Answering from my phone before, I didn't see your pic until now. Do you intend to model a real world bldg (i.e. does accuracy matter)? If not, I'd go with Chris' solution. Otherwise (apart from the fact that what you show is a very unlikely roof – I say this as an architect), one way to go might be to try to determine the width of the main body of your building. The problem has nothing to do with hip or gable roof. Rather, the heart of the matter is that the roof builds from the main body of the building, with all protruding building parts (three extensions to the back and left, the sort of bay window part in the front and the side wing on the right) cladding on to the main envelope. I would assume, that convexify() might help you to isolate the main body of the building in order to retrieve the width. From there, I would do the tan(roofAngle) * buildingWidth / 2 thing. But maybe some of the CE guys have a more clever approach… ... View more

If I understand your problem correctly, you need to know the roof angle. The distance which you would want to subtract from your hipHeight to get your facadeHeight would be something like cos(roofAngle) * buildingWidth / 2. Nic Short message from my phone. Den 10/09/2015 kl. 22.11 skrev Gregory Jameson <[email protected]<mailto:[email protected]>>: GeoNet <https://community.esri.com/?et=watches.email.thread> Roof Height in CE created by Gregory Jameson<https://community.esri.com/people/GregoryJameson?et=watches.email.thread> in CityEngine - View the full discussion<https://community.esri.com/message/550592?et=watches.email.thread#550592> ... View more

Thanxissimo! This means the world to me – or at least my simulation of it… Although, I don't really understand what happens (which, of course, annoys me, as I won't be able to replicate the trick in another context). How does the script know which geometry.area to use in attr lotArea? I use the geometry.area function in more places throughout the script. In addition, attr lotArea is no longer referenced anywhere in the script. Also, it seems that the parent attr does not simply overrule the namesake child attr. Rather it seems to work in conjunction with it: I cannot write whatever value for the child attr (this would be the case if it was overwritten, I suppose). It must be set to geometry.area like the parent attr in order to work. How is that? PS: Yes, the console is truly helpful when debugging. ... View more

Yes, the split command has the correct syntax in my actual rule file – don't know why it's missing above… Anyway, I still cannot make the child file adopt the attribute values of namesake attributes in the parent file. The issue is not just an aesthetic one (that it looks nicer). Passing on parameters a long way is also more prone to errors. Besides, I plan to link multiple child files to the parent file, all of which will use the lotArea parameter value. It is going to be a lot of Ariadne threads of parameters to keep track of. As you see, I inserted a report("testChildLotArea",lotArea) operation in the Footprint rule of the child rule. In the inspector, this reports the initial value of the attribute (of the child rule file). Had the value been passed on from the parent rule file equivalent, I would expect that value (which is set) to be reported. Or am I wrong? Any suggestions to a solution? Is it a CE 2015.1 bug? ... View more

Hmm… I can make it work using a parameter, but I'll have to pass it on quite a bit, which I don't find very neat. According to 1. in your answer, it would be possible to set an attr in the parent rule and pass it on to the child rule. It would be nicer to set the value of an attr lotArea in the parent rule and pass it on to an identical attr in the child rule. But that doesn't seem to work. I made a test report of attr lotArea in both parent and child rule, but it only reported correctly from the parent rule. I pasted both rules below. Did I misunderstand something? /** * File:    parent_rule.cga * Created: 27 Aug 2015 21:22:33 GMT * Author:  Nic */ version "2015.1" import f1 : "child_rule.cga" attr lotArea = 1 Lot --> case scope.sx < scope.sz : rotateScope(0,90,0) X(geometry.area)   else : X(geometry.area) X(sqm) --> report("lotArea", geometry.area)   set(lotArea, geometry.area)   report("testParentLotArea", lotArea)   split(x) { '0.5 : Footprint(sqm) | '0.5 : Green } Footprint(sqm) --> f1.Footprint(sqm) Green --> color(0.5,1,0.5) /** * File:    child_rule.cga * Created: 27 Aug 2015 21:22:59 GMT * Author:  Nic */ version "2015.1" attr bldgH = 12 attr floorH = 3 attr lotArea = 1 Footprint(sqm) --> report("testChildLotArea",lotArea)   extrude(bldgH)   Envelope(sqm) Envelope(sqm) --> split(y) { ~floorH : Floor(sqm) }* Floor(sqm) --> comp(f) { bottom : FloorShape(sqm) } FloorShape(sqm) --> report("floorArea",geometry.area)   report("FAR", geometry.area/sqm) # Here I would prefer to insert the attribute "lotArea" instead of the parameter "sqm" ... View more

Hi, thanks for your swift reply. I am not easy to satisfy… As I would like to do a human evaluation of different rotations, spacings, etc., of the housing scheme on the terrain before settling for a final solution, this would be a tedious approach. Meanwhile, I have been testing the "Combine Shapes" and "Convert Models to Shapes" commands in order to get a 'tiled' Shape to work from (pic). The problem with that seems to be, that the tiles need to add up with the spacings in the script in order not to generate extra sub-shapes whenever the Shape folds… Initial shape generated with Combine Shapes command applied to 6 adjacent shapes Script applied to the above Shape. Extra lines are generated where the Shape is 'stitched' together. ... View more

Hi Matt, actually it was me (same guy) who asked that question 2 years ago. I got away from this problem, and now I picked it up again. I didn't get any closer to a solution though: I need a way to align sub-shapes to the terrain. You suggested back then to either use static shapes or graphs. Good ideas, but none of them work for my particular purpose, as my ambition is to be able to script the whole thing, rather than to import/draw specific shapes/graphs. When a shape is aligned to a terrain, it seems that the surface height is interpolated from the edges rather than calculated locally from the terrain map. This means that local hills and depressions (inside the shape) will not be reflected in the alignment of the shape to the terrain (see pic). As sub-shapes are generated from the initial shape, significant deviations from the actual terrain may occur. My question, therefore, is if there is any way to (re-)align sub-shapes to the terrain? Would it be possible, for instance, to compare the scope.elevation of the sub-shape to the elevation attribute of the map layer at the sub-shape's location and add/subtract the difference? ... View more

Hi Jacqueline, Another neat way to solve your problem would be to color your floors by directly using the Y coordinate of your floor in the color() operation. In this example, I have used floor() in order to "step" your color scale. This also allows you to control the number of shades in your color scale by an attribute. I used the colorRamp() function, but you may of course incorporate this approach directly into color() if you prefer. This rule would also work for different situations without having to recalculate you case/else steps manually. Best, Nic /** * File:    colorByFloor.cga * Created: 7 Jul 2015 08:52:51 GMT * Author:  Nic */ version "2015.0" attr maxFloorY = 100 attr minFloorY = 0 attr HeightRange = maxFloorY-minFloorY attr numberOfShades = 20 @Startrule Lot --> extrude(maxFloorY) split(y) {~3 : Floor }* Floor --> color(colorRamp("spectrum", (floor(scope.elevation/HeightRange*numberOfShades)/numberOfShades))) ... View more

This is genuinely cool, Chris. It opened up a whole new vocabulary of design for me. Thanks a lot! Just to wrap up on trim(): As I understand, it only works on faces which originate from comp() as trim planes must come from something. In turn, trim planes are inherited all the way down subsequent shapes. This is not very clear from the documentation. This makes comp() in combination with trim() an essential design tool for more complex forms. To answer your curiosity question: Yes. Utzon did a couple of housing developments where houses are arranged in chains and clusters in contoured landscapes (see pics). I am studying how to adapt his principles to other sites and terrains. This in fact opens up some more questions, but I will ask those in a new thread. Thank again. ... View more

My example is obviously a simplified version. Key issue is how to get such perpendicular shed roofs to join without overlapping geometry. Here's a photo of the real thing: ... View more