Latest Contributions by CherylLau

You could apply a component split to get all the faces of your object and then apply a rule to each face.  The rule could set the height of building.  (For the following code, assign the start rule Lot to your initial shape.) Lot -->      comp(f) { all : Face } Face -->           extrude(rand()*20 + 0.5*MEAN_Z)     // set height to random value in [MEAN_Z - 10, MEAN_Z + 10] ... View more

Does the scene file (tracksScene.cej) in the zip file work for you?  Do you still have unknown asset problems with the included scene file? ... View more

If you try to open the scene file (tracksScene.cej) in CE 2015.2, then the railroad tracks do not look curved.  Is this what you're talking about when you say it's not working?  This might be because this code was written for an earlier version of CityEngine, and things have changed since then.  To fix this, you can select all shapes (right click in viewport -> Select -> Select All) and then make the graph segments curved by going to Graph -> Set Curves Smooth. For the missing texture files, I'm guessing you are referring to the warnings generated about not being able to find the .mtl files.  This is ok because it doesn't affect the generation of models in the scene, and you don't need to do anything.  There are no texture files (mtl files) associated with these obj files.  If you want to make these warnings go away, you can edit the obj files and remove all the lines that contain anything to do with "mtl". ... View more

Agreed.  A standalone rule makes the most sense in this case. Good point, Chris, that the input data could likely be GIS point data.  And, good idea, David, to import it into the street rule if you want to make the overhead sign align with the street's v coordinate, for example. ... View more

You could write a rule to put a street sign on the corner of a shape of type junction or crossing (Street and Crossing Shapes ).  However, it is only possible to figure out the direction of the main street in the junction.  Unfortunately, we cannot yet determine the angle of the intersecting street from a junction shape.  So, if your streets are all at 90 degrees, then you can hard code your sign posts to have the second street name sign at a 90 deg angle from the first street name sign, but I realize this is not ideal as streets are not always 90 deg to each other.  Thank you though for sharing your issue as it is good for us to know these use cases. To make the highway signs over the road, maybe you could position them using the u coordinate which goes along the street. ... View more

As for Pro, aligning a single 4-vertex polygon to the terrain is not possible (except when you drape it onto the terrain, but this doesn't actually change the polygon, so the rule won't work as desired in this case).  You would have to add more vertices to the polygon and align those to the terrain.  But, if you apply your cga rule to the non-flat polygon, then it probably won't work as intended. So, if you can break up the polygon into several smaller polygons and align each of those to the terrain, this would get you closer to aligning your geometry to the terrain. We are working on similar problems, and I know this is a tricky issue.  We are glad to have your feedback as it gives us a valid use case, so thank you for sharing it. ... View more

I'm not sure why the power line is floating in the air.  I don't think it's the code because it seems to work in CityEngine.  However, the code does have some scope changes that could be avoided.  Here is a shorter version that you could try out to see if the power line still floats. version "2015.2" attr avstand         = 200           // gap between the poles attr hoyde           = 30            // hight attr bredde          = 20            // width attr farge           = "#808080"     // color hatta                          = "assets/Sketchup/LyseMastNormal5.dae" //asset (both powerline and pole merged) @InPolygon @StartRule trase -->       alignScopeToGeometry(yUp, any, longest)    rotateScope(0, 90, 0)       split(z){~avstand: lagHoyspent}*               lagHoyspent -->       s(bredde, hoyde, avstand) center(x)       i(hatta)       color (farge) ... View more

Hi Jørn. To better understand what alignScopeToGeometry() is doing, you can use the Model Hierarchy (Window -> Show Model Hierarchy).  This let you see the scope axis for your objects at each level in the rules.  Click on your model in the scene, and then click on the "Inspect Model" button (2nd button to the right of the "Generate" button on the toolbar along the top).  Then a tree shows up in the Model Hierarchy window.  It starts with your root node (trase), and the next level of the tree is the rule lagHoyspent.  Click on this level to see how the scope is positioned when you call this rule (right before the rule is executed, after the split).  On the model, the x axis is drawn in red, y is green, and z is blue.  The last level in the tree shows how the scope is positioned after the rule lagHoyspent is completely exectued.  alignScopeToGeometry(yUp, any, longest) aligns the x axis to the longest edge. Hopefully, the Model Hierarchy would help you understand what was going on with the translation problem as well. I'm glad you found a solution (Ben, thanks for the solution!).  Be careful though because it might work differently for both cases of polygons where (a) the short side of the polygon is larger than avstand or (b) the short side of the polygon is smaller than avstand.  Perhaps you don't need to care about both cases though. Another solution would be to align the x axis to the longest edge of your polygon, then split in x, and then without realigning the scope, just resize the scope and insert the object. @StartRule trase -->       alignScopeToGeometry(yUp, any, longest)       split(x){~avstand: lagHoyspent}*               lagHoyspent -->       s('1, hoyde, bredde) // the scope size in the x dir will be avstand from the split    center(z)       i(poleAsset)       color (farge) ... View more

Hi Jørn. One solution would be to align the scope to the longest edge using alignScopeToGeometry().  This will align the x axis with the longest edge (of the largest face), and you can do your split in x as before.  For the first parameter, you can pick y or z to be the axis that goes upwards (along the face normal). alignScopeToGeometry(yUp, any, longest) See the help documentation for a description of the possible parameters. alignScopeToAxis Operation  ... View more

To create column charts and pie charts with multiple columns/slices, generate a report with sub-reports using a period (.) to separate the report and sub-report names.  For example, if you'd like to create a chart that reports GFA for different types of buildings (e.g., retail, residential, office, hospital, etc.), then, generate reports in CGA with the following names:  GFA.Retail, GFA.Residential, GFA.Office, GFA.Hospital, etc. report("GFA.Retail", geometry.area) report("GFA.Residential", geometry.area) Or, if you have the building type in a variable, you can create strings for the report name: buildingType = "Office" reportName = "GFA." + buildingType report(reportName, geometry.area) More about creating sub-reports can be found in Tutorial 11 in the "Greenspace and BuildUp Area Reports" section:  Tutorial 11: Reporting—CityEngine Tutorials | ArcGIS for Desktop Then, create the dashboard by selecting "GFA" as the "Report". ... View more

Hi Scott. I'd like to emphasize again that the best solution would be to turn on wireframe visualization in LumenRT instead of adding extra geometry to your models.  Adding extra geometry increases the complexity of the scene unnecessarily, duplicates edges, and may not even look good when rendered. However, if you just need a hacky solution, you can apply the rule as follows to your shapes: Shape -->      ColoredShape      Wireframe ColoredShape -->      color(1, 1, 1) Wireframe -->      comp(e) { all : color(0, 0, 0) Edge. } ... View more

Hi Scott. You could try coloring all the edges black (this creates extra geometry) for all the geometry in the building. BuildingPart -->      // do stuff to make building part      Geometry.          // add this line to make sure geometry is generated as well as the wireframe      Wireframe Wireframe -->   comp(e) { all : color(0, 0, 0) Edge. } But, I feel like using a rule to create extra geometry is not the best way to go because seeing the wireframe should be controlled by a visualization mode property and not by adding extra geometry.  The best solution would be if there is a wireframe visualization mode in LumenRT, but you probably wouldn't ask this question if this is the case. ... View more

Hi Felix. This is a strange bug in the 2014 version.  This does not happen in the 2015 version. It seems like the function floorHeight("GF") is causing the problem, and you can trick it by multiplying by one, and the compile error goes away: BuildVolume -->      split(y) { 1*floorHeight("GF") : Volume("GF")                  | ~1 : UpperFloors } As a side note, the rule does not generate the building as intended because the scope.sy value, which is passed to ScopeAligned, is zero.  Then, yDim is set to 0 in the ScopeAligned rule.  To fix this, pass it a non-zero value so that the BaseVolume has a non-zero height. ... View more