modelling real-world building complexes

[BenLeslie1]

Hi City Engineers

I am modelling some real-world building complexes so I am working with predefined building footprints each with separate heights.  But I also want to apply rules based on the overall dimensions of the complex.

So, I want to somehow combine shapes but keep attribution separate - any cunning tips that might allow me to do this?

[MatthiasBuehler1]

sure..


just check based on scope.sx and scope.sz, geometry.area() and geometry.isConcave.

that way, in CGA, you can classify what type of footprints you have, then link to different rules for that typology.


usually, classifying on shape area, scope width and depth is enough.

makes sense or do you need more input ?

m.

[BenLeslie1]

Hi Matt,

I'm afraid I don't understand - but it's possible I didn't explain the problem very well; let me have another go:

I want to position lights on the top of large buildings, but these buildings could actually be draw as several small buildings because they have different heights. 

See attached image - let's say I want lights on any building longer than 50m and each of those red or blue blocks are 20m in length.  I want CityEngine to somehow recognise that the blue blocks form a 60m building and put lights on it.

[ATTACH=CONFIG]29966[/ATTACH]

If I created a "buildingName" attribute and gave all the blue blocks a common name, could I somehow use that to make CE recognise they are all one building?

Thanks
Ben

[MatthiasBuehler1]

Hi,

CGA starts on a shape and has no information about neighbors what so ever. This is a limitation of CGA currently. The only exception is occlusion queries ( see docs ), but those cannot query any other specific parameters of neighbors.

The only way you can do this currently is using Python to inform your buildings that they touch each other and have a combined length of 60.

E.g. also use these steps:

Model Generation 1 : create no lights, but create reports
Python: Evaluate reports and write attribute data ( e.g. 'is big building, thus add lights on top' )
Model Generation 2: pick up attribute, generate lights !

e.g. if you have an attribute called 'wasGeneratedAlready = 0', you know in CGA that you don't want to add lights but report. After Python wrote the attr as 1, you create the lights.

[Note that all those 3 steps can be combined in 1 Python script, if needed. You'd be using the script based exporter in this workflow.]