Latest Contributions by AndréCardoso

Hey Simon, Any news on the DAE bug? hi there no, you are not alone working on linux, but we are a minority 😄 i am actually developing CityEngine on a gentoo box. 1) will look into this and report back asap 2) yes, this is a known issue. all i can say is that we hope to fix it for 2013.1 🙂 best, simon ... View more

Haaa, another gentoo guy. I like you already 😛 Thanks a lot Simon 🙂 hi there no, you are not alone working on linux, but we are a minority 😄 i am actually developing CityEngine on a gentoo box. 1) will look into this and report back asap 2) yes, this is a known issue. all i can say is that we hope to fix it for 2013.1 🙂 best, simon ... View more

Ha, this is very very cool, very useful! I should come by the forums more often 😛 Hi guys .. Yes, this works. Just usually, I don't import a master rule into an other 'god rule'. 🙂 I try to pass down all values needed from the master rule down to the slave rules, if somehow possible. What's also not so beautiful is if each slave rule itself imports e.g. a 'general reporting' rule, you will see instances of that rule in the Inspector ( each selectable ), which is visually confusing. Thus, note the structure in the following example .. I guess it gives the best overall import structures : code in cga file the master file "a.cga", which is assigned to the shape, with Start Rule A : import b : "b.cga" import c : "c.cga" A -->     b.B b.Mass -->     c.ReportBottom     code in cga file "b.cga" : B -->     extrude(world.y, 10)     Mass     # note that Mass must remain an 'undefined rule', so you'll not be able to avoid the yellow warning. code in cga file "c.cga" : ReportBottom -->     report("BottomArea", geometry.area(bottom) ) As you see in those 3 rule files, all content is 'distributed' from the master file 'a' to 'b' and then taken back to a to be sent to 'c' for reporting. That way, you can create rules, which e.g. creates all Masses alone, all Roofs alone, all Facades alone and distribute all via the master rule file, then cycle it back. This is advanced shit, boys ! ... View more

On the script entry, one of the attr definitions says: '/ce/rule/wallC': {                              0: 0,                              1: ["#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF", "#000000", "#FFFFFF"]                              } The code is just going through that list of colors (white, black, white, black), for the "wallC" attr... There were more interesting things to do, but I just wanted to share the code and I don't have much time to do these things :rolleyes: Ultimately, what I've shared may not have direct utilization by others on this community, but it might spark some ideas... hope it does 🙂 Hey Andre ! Cool work ! Why's the model changing to black each second step ? Cheers ! Matt ... View more

That... makes perfect sense :rolleyes: Thanks! hi ! the default color is just white color(1,1,1) // or legacy : color("#ffffff") to find the default material attributes, just try to print those you're interested in. resetting just means setting the value back to the first value. ... View more

Hey, bellow are the rules to build a simple stairway from a rectangular base. It is very simple, and the results are nothing spectacular, but it might be interesting for some one out there 🙂 The pictures show how we can parametrize the function call, and control the model through the inspector... [ATTACH=CONFIG]15682[/ATTACH] [ATTACH=CONFIG]15683[/ATTACH] [ATTACH=CONFIG]15684[/ATTACH] [ATTACH=CONFIG]15685[/ATTACH] [ATTACH=CONFIG]15686[/ATTACH] const stairStepUnitRise = 0.17 const stairStepUnitRun = 0.28 @Hidden attr currentScopeSx = 0 ## dummy, calling rule bellow with some defaults ## the level has, by default, 45% of the lenght of the shape in x StairwayWithLevel(topColor, frontColor, levelColor) --> StairwayWithLevel(topColor, frontColor, levelColor, 0, 0, 0) StairwayWithLevel(topColor, frontColor, levelColor, levelDim, centerDim, displacement) --> set(currentScopeSx, scope.sx) ## first, divide into level and two stair flight of stairs split(x){   (0.45 * scope.sx) + levelDim:                         StairwayLevel(levelColor, currentScopeSx*0.45+ levelDim, currentScopeSx) |   ~1:    split(z){     ~1 + displacement:                                         t(0, ((rint((currentScopeSx-(currentScopeSx*0.45+ levelDim)) / stairStepUnitRun)) - 1)*stairStepUnitRise, 0)                                         StairFlight(topColor, frontColor) |     centerDim:                                         NIL|     ~1:                                       rotateScope(0, 180, 0)                                       StairFlight(topColor, frontColor)    } } StairwayLevel(levelColor, length, total) --> t(0, ((rint((total-length) / stairStepUnitRun)) - 1)*stairStepUnitRise, 0) s('1, stairStepUnitRise, '1) i("builtin:cube") comp(f){   top:    color(levelColor)    set(material.specular.r, 0)    set(material.specular.g, 0)    set(material.specular.b, 0)    set(material.shininess, 0)    set(material.opacity, 1)    SetMaterial("stairwaylevel")|   all:    SetMaterial("stairwaylevel")    } StairFlight(topColor, frontColor) --> split(x){   ~stairStepUnitRun:    t(0, (split.index)*stairStepUnitRise, 0)    StairwayStep(topColor, frontColor)   |   {    stairStepUnitRun:     t(0, (split.index)*stairStepUnitRise, 0)     StairwayStep(topColor, frontColor)   }*  } StairwayStep(topColor, frontColor) --> s('1, stairStepUnitRise, '1) i("builtin:cube") comp(f){   top:    color(topColor)    set(material.specular.r, 0)    set(material.specular.g, 0)    set(material.specular.b, 0)    set(material.shininess, 0)    set(material.opacity, 1)    SetMaterial("stairwaystep")|   all:    color(frontColor)    set(material.specular.r, 0)    set(material.specular.g, 0)    set(material.specular.b, 0)    set(material.shininess, 0)    set(material.opacity, 1)    SetMaterial("stairwaystep")    } SetMaterial(name) --> set(material.name, name) TerminalMaterial. ... View more

Exactly! For me, one the great things added in these recent versions of CE was the capability to use "set()" with attributes defined by us. Things get much cleaner... 🙂 ... View more

Another possibility is just to pass the original area down to the next rules, as Rule parameters... Lot --> Rule2(geometry.area) Rule2(area) --> Rule3(area) ... ... View more

I'm not sure what you have tried to do already ... but have you tried to use the "set(attr, attrValue)" function? Something like this: @Hidden attr originalArea = 0 Lot -->    print("Original Area", geometry.area)    set(originalArea, geometry.area)    BuildShape BuildShape -->     shapeL(3, 4){shape: ShapeRule | remainder: NIL} ShapeRule -->    alignScopeToAxes(y)    print("Original Area Again", originalArea)    print("Current Shape area", geometry.area)    extrude(world.y, originalArea/8) # calculate height in function of oriignal footprint area    Shape. Does it work? ... View more

Just for reference, if you have trouble downloading the examples form within CityEngine, you can try downloading them directly from here: http://www.procedural.com/ce_projects/ce_2011.2/examples/ Then unzip them, and import them to CityEngine, using the import dialog. ... View more

You can use the setback operation, in a recursive manner. I think any solution depends on some more details of your problem... The solution I provide bellow does not seem very elegant, nor it works in every situation... but it might get you going for now... 🙂 [ATTACH=CONFIG]13159[/ATTACH] version "2011.2" attr buildingHeight = 10 attr buildingColor = "#4A708B" attr leftColor = "#FF0000" attr rightColor = "#0000FF" attr backColor = "#FFA500" attr frontColor = "#800080" attr frontSetback = 2 attr leftSetback = 8 attr rightSetback = 4 attr backSetback = 10 @StartRule LotInner -->     NIL.    @StartRule LotCorner -->     NIL. @StartRule Lot -->     setback(frontSetback){         front: color(frontColor) FrontPart.|         remainder: MinusFront     } MinusFront -->     setback(leftSetback){         left: color(leftColor) LeftPart.|         remainder: MinusFrontAndLeft     } MinusFrontAndLeft -->     setback(rightSetback){         right: color(rightColor) RightPart.|         remainder: MinusFrontLeftAndRight     }    MinusFrontLeftAndRight -->     setback(backSetback){         back: color(backColor) BackPart.|         remainder: MinusFrontLeftRightAndBack     } MinusFrontLeftRightAndBack -->     Mass Mass -->     alignScopeToAxes(y)     extrude(world.y, buildingHeight)     color(buildingColor)     Mass. I don't know any documentation in spanish though :S I normally use the application help menu window, and this forum 🙂 Hope it helps!! ... View more

The CE documentation talks about terrain layer attributes and functions... Here is an example of a spherical terrain: attr SCALE = 1000 attr R = 500 attr elevation =   case sqrt( ( pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2)) ) > R:    0.0   else:    case sqrt(R*R - (pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2))) < 0:     0    else:     sqrt(R*R - (pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2))) Don't know if anyone noticed, but there's a bug 😛 To get the half  sphere, we only need this: attr SCALE = 1000 attr R = 500 attr elevation =   case sqrt( ( pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2)) ) > R:    0.0   else:    sqrt(R*R - (pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2))) [ATTACH=CONFIG]13095[/ATTACH] I think sqrt is always > 0... lol The erased part might be useful if you want just the top of a sphere, to make a slightly rounded terrain. For example: [ATTACH=CONFIG]13094[/ATTACH] attr SCALE = 1000 attr R = 1500 attr elevation =   case sqrt( ( pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2)) ) > R:    0.0   else:    case sqrt(R*R - (pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2))) - 1430 < 0:     0    else:     (sqrt(R*R - (pow((u-0.5)*SCALE, 2) + pow((v-0.5)*SCALE, 2))) - 1430) + elevationDelta ... View more

Ok, I think I found out what was going on 🙂 and it was my fault :S On the matter of my imports not working: - startup.py makes CE do a "import startup"; if, inside your custom "startup.py", you do a "import fantastic_module", then on the python console you'll need to do something like: >>> startup.fantastic_module.foo() to call your functions. And my problem was that I simply was not starting my call with "startup.", instead I was trying to access the modules directly.... My fault! I think Andreas Ulmer tried to explain this to me on the first post 😄 but I did not quite get at the time! - on the other hand, if you create a "scripting.py" inside the workspace root, their contents are copied to the CE own initialization script; So, if inside "scripting.py" you do a "import fantastic_module", then on the console you'll need to something like: >>> fantastic_module.foo() So, sorry for the entropy caused here :S **** Nevertheless, I was able replicate the behaviour concerning the cache, on linux: - when I delete the startup or scripting file from the workspace, they continue to exist in cache. I'm forced to delete the "scripting.py", "startup.py" and associated *.class files to reset the scripting environments. ... View more