Latest Contributions by DanielO_Shaughnessy

‎07-24-2012

This is a bit like a CGA I have been working on for some typical blocks in Chicago. I use 4 different roof types: flat, corniced, hip, and gable.....and then allow the user to choose one type per block or randomize roof shapes. Here is what mine look like: [ATTACH=CONFIG]16365[/ATTACH] Happy to share the code if anyone wants it.

‎07-09-2012

This is probably a question best-suited to matthias....but here is a shot at your answer: 1) I think this has to do with how CityEngine reads rule hierarchy. Ie, instead of proceeding from one line in the rule down to the next (which is how I conceptualize coding), it proceeds from one rule (in its entirety) to the next. In your case, then, you would have to separate it out: Start --> alignScopeToAxes(y) s(assetSize("assets/facades/gazeboBeam_1.obj", "x"),assetSize("assets/facades/gazeboBeam_1.obj", "y"),assetSize("assets/facades/gazeboBeam_1.obj", "z")) i("assets/facades/gazeboBeam_1.obj") posCheck posCheck --> case pos == "center_xz": center(xz) case pos == "right": t('scope.sx - (assetSize("assets/facades/gazeboBeam_1.obj", "x") / 2), 0, 0) else: DoNothing Alternatively, you could repeat the first bit of code after each conditional statement: case pos == "center_xz": alignScopeToAxes(y) s(assetSize("assets/facades/gazeboBeam_1.obj", "x"),assetSize("assets/facades/gazeboBeam_1.obj", "y"),assetSize("assets/facades/gazeboBeam_1.obj", "z")) i("assets/facades/gazeboBeam_1.obj") center(xz) ....etc 2) If you don't include an else statement, then the conditional remains open. Ie, everything after your last line is still part of the "case" - right? Adding in the "DoNothing" rule as you did is one solution, as is simply using NIL. And for the record, every conditional always includes some sort of "else" condition....otherwise there wouldn't be a conditional to begin with 😉

‎07-05-2012

Good evening, In order to streamline the process of calculating program at a project-wide level, we would like to be able to import models generated with other software (Rhino, for example) and use CityEngine to quickly come up with GFA by program type, FAR, etc. To do this, we wrote a simple script that imports a model as .OBJ, splits that model into "floors" based on an input floor height, reports floor areas, and displays the models split into floors and colored by land use. No problem, right? This works like a charm as long as you deal with small models - one block at a time, simple geometry, etc. But as it becomes more complicated, the script falls apart for some reason. Here are some screen shots from my own tests showing this problem. 1) Original Rhino file for the test...I've added 4 different model "types" to test out. [ATTACH=CONFIG]15798[/ATTACH] 2) Single building - works great! [ATTACH=CONFIG]15799[/ATTACH] 3) Two buildings - also works great! [ATTACH=CONFIG]15800[/ATTACH] 4) Simple block - 8 different buildings and still working! [ATTACH=CONFIG]15801[/ATTACH] 5) Complex block - circles, funky angles, and still working! [ATTACH=CONFIG]15802[/ATTACH] Some examples of this NOT working following the break.....5 images is the max per post....

‎06-21-2012

Hi Matthias, A quick question to follow this one.... I created some rules and a test scene with the full licensed version (64 bit), but have opened that scene in a trial version (32 bit). Everything seems to be working except that I can't get any colors to display. All models are basic white, and even the ability to turn on shadows is grayed out in the drop-down menu. Is this a version problem, or am I missing something far simpler? Thanks

‎04-23-2012

Thanks Matthias (or is it Matt?) - turns out this is also very helpful if you are importing a model and want, for example, to keep the ground plane green under the imported buidling. The result still generates some overlapping geometries (ie, the full lot, even under the imported model, is green), but I don't see a better way around it.

‎04-23-2012

hi Daniel, that's easily possible : Just select your Block, then set the cornerWidth parameter to something larger than 0. (Just below the Block Subdivision Type parameter) Let me know if it works ! Yes, this works quite well - thanks! Just a bit of feedback: it would be nice if information like this was searchable in the Help documentation. So here is one further complication. In addition to creating the chamfered parcel boundaries, we also need to have the "development zone" within that parcel maintain a (near) rectangular shape, instead of the octagon that gets created using the cornerWidth parameter. Ie, buidings should stay aligned to the streets instead of aligning to the chamfered parcel boundary. To do that, I could see using the chamfer to define lot setbacks, but any use of the "setback" operation will produce funky shapes. [ATTACH=CONFIG]13739[/ATTACH] Any ideas?

‎04-23-2012

Good morning, For many of our Chinese projects, we are faced with the problem of creating parcel boundaries that have chamfered corners. This can be a laborious task in CAD, particularly if you have hundreds of blocks. [ATTACH=CONFIG]13732[/ATTACH] It seems like CityEngine could be used to automatically generate these parcel lines (in addition to curb lines, etc), but I can't come up with a way to actually do it. What we would be interested in is just a simple chamfer on each of the lot's corners, before additional rules are applied. In our case, we are NOT using built-in lot subdivisions, so just assume it's the entire block that needs to be setback somehow. In the simplest case, the chamfer distance is the same in all directions, but that value should be user adjustable. Any thoughts on how to approach this problem?

‎04-18-2012

Thanks for the reply. I was able to recreate your results for blocks that use built-in subdivision tools (recursive, offset, etc). Unfortunately, the rules we are developing are all built on full lots with no subdivision...essentially giving us control of the size and shape of "parcels." When I try the same approach on this block, all elements of the block take on the same streetWidth(i) attributes, even if they are subsequently split apart and no longer touch the streets. See the image below for what I mean: [ATTACH=CONFIG]13644[/ATTACH] Is there a way, perhaps, to identify which side of the block is actually touching the largest street? Even returning a direction (N,S,E, or W) could work.

‎04-18-2012

Hi all, I am working on designing a "typical" city block that includes basic row houses. I have managed to figure out the general shape grammar and even add unique cases for when the block borders a commercial street (see image below). [ATTACH=CONFIG]13633[/ATTACH] The problem is that, right now, these unique cases are essentially just hard-coded in based on a user-specified typology. What I would like instead is for the block to be able to draw information from adjacent streets. Ie, it should know when the "type" of an adjacent street is "COMMERCIAL" (for example) and use that information to trigger the new block shape. Is there a way to access street attributes in the CGA script? There are clearly width values stored as Object Attributes called streetWidth(0), streetWidth(1), etc....but how do you reference these in your code? Any help is appreciated...

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by DanielO_Shaughnessy

Re: CGA : Simple Roofs

Re: few conditional rule questions

Splitting imported models

Re: Free Trial Version vs Full License Version

Re: face culling when scattering

Re: Chamfer Lot Corners

Chamfer Lot Corners

Re: Accessing Street Attributes

Accessing Street Attributes

Re: CGA : Simple Roofs