Latest Contributions by CherylLau

Without splitArea() it is not really possible to divide a lot into a piece that is exactly 3000 sqm or end up with exactly 33% of the original area as green space.  However, you might be able to achieve approximate results.  Here are some ideas to explore: * Recursion.  You can recursively split your parcel until your desired stopping criteria.  Maybe this criteria could involve the area or dimensions of the final lot?  Maybe the split chosen at each level depends on the area or dimensions of the current lot? * geometry.area().  This function will give you the area of the geometry.  geometry Functions  * scope.sx, scope.sz.  These will give you the size of the scope.  If you have rectangular lots, this might be helpful in calculating how large of a split to perform in order to get a certain area.  Of course, if you don't have rectangular lots, this calculation won't work.  scope Shape Attribute  * Stochastic rules.  If you divide a rectangular lot into equal sized cells (like a grid), then you can use a stochastic rule to make 33% of the lots green space and 27% of the lots open space and etc, for example.  Stochastic Rule  * Reports.  You can check how close you got to your goal by reporting the exact area. report("Area.GreenSpace", geometry.area) report("Area.OpenSpace", geometry.area) report("Area.BuildingSpace", geometry.area) ‍‍‍ * Tutorial 11.  In this tutorial, there is an attribute called greenspacePercentage.  It doesn't divide the space exactly according to the percentage set in the attribute, but it is approximate.  This can be seen in the reported values Area.Greenspace and Area.BuildUp.  You can see how the approximation was made in the Lot rule where it chooses to be GreenSpace or a BuildingLot based on this greenspacePercentage.  Tutorial 11: Reporting—CityEngine Tutorials | ArcGIS Desktop  ... View more

The advice that I could give is to look at what your floors have in common, and see if you can find some common attributes.  They don't have to share the same values.  If so, then you can probably write a single floor rule that covers all cases.  If not, then maybe you do need several floor rules. For example, the floor rule can have an attribute for the number of apartments.  In the parent rule, you can set this attribute to different values for each floor using set(). set Operation  This rule sets the number of apartments to 1 for the ground floor and sets the number of apartments to 10 for all other floors. Floor -->    case split.index==0:       set(floor.numApts, 1)       f0.floor    else:       set(floor.numApts, 10)‍‍‍‍‍‍       f0.floor‍‍‍‍‍‍‍ Remember that you can also have attributes like floorLayout which can have values such as {"GrandLobby", "OShaped", "SingleHallwayWithApartmentsOnEachSide"}.  Then, in the floor rule, based on this attribute, you can decide whether to create a single large lobby, a floor with apartments arranged around the edges in an O shape, or a floor with a single hallway down the middle and apartments on each side.  These are just simplified examples to illustrate some things you can do with attributes. ... View more

I don't understand your question, but I will make a guess that you want to split in two directions in order to partition a lot so that there is a courtyard in the middle. Splits can only be made in one direction at a time (also applies to splitArea).  To split a lot in two directions, you will have to perform two splits, one after another. Alternatively, you can use offset, setback, shapeL, shapeU, and shapeO to create L, U, and O shapes.  However, you cannot specify an exact area with these functions. offset Operation  setback Operation  shapeL, shapeU, shapeO operations  Yes, you can apply recursion in cga to partition lots recursively.  For example, if you apply shapeO to a lot, you can get a courtyard area in the middle.  Then, you can apply the rule again to the courtyard, you can subdivide the courtyard into another shapeO (or whatever function you want), and you can keep subdividing resulting pieces until your desired stopping criteria. ... View more

It's in the changelog.  A link to it can be found at the bottom of the cga reference page. CGA Changelog  ... View more

Sorry, at this point in time, I don't think this is possible.  I don't think the logical OR is available in the search field. If you want to write a python script though, you can probably do this. ... View more

Changing the height using an attribute (rather than converting to shapes and editing vertices) is the way to go, so finding a rule that lets you do that is probably a better solution. The Building_From_Footprint.cga rule in ESRI.lib is a rule that lets you change the eave height and the ridge height of your building.  Maybe this is of interest to you? ... View more

You can use wildcards to search for multiple items with similar names.  For example, if you search for "*Broadway", you will get all the ones on Broadway.  Note that *Broadway and "*Broadway" might give you different results.  For example, the former will include a shape called 23 Broadway North (and all shapes with the word Broadway in it), but the latter will not.  You can also use spaces to signify a logical AND.  Here is the help page (look at the Search Field section at the bottom), but it's not quite up to date unfortunately.  I can only advise to just experiment with the wildcards and spaces at this point in time. The Scene Editor  ... View more

The splitArea() function is only available starting with 2016.0, but I would recommend upgrading to the latest, which is currently 2016.1. With the splitArea() function, you can split a shape by percentage area. splitArea Operation  For example, this split divides the area of the current geometry into 33% green space, 27% open space, and 40% building space: splitArea(x) { '0.33: GreenSpace | '0.27: OpenSpace | ~1: BuildingSpace }‍ You can also split the current geometry according to an absolute area.  For example, this split divides the area of the current geometry into one piece that has exactly 3000 sqm and one piece that has the remaining area. splitArea(x) { 3000: BuildingSpace | ~1: OtherSpace }‍ Note that splitArea (and split) only splits the geometry in one direction.  If you want to split in two directions (e.g. x and z), you'll have to do nested splits (as you figured out). The reason why the percentages in the code you wrote don't work the way you expected is because the percentage syntax has a different meaning.  It means that the rule will choose one of the cases with some probability, and that probability is defined by the percentage.  So, if the rule is executed 100 times, it will choose to create ExtrudeBuilding approximately 35 times, and it will choose to create OpenSpace approximately 27 times. Stochastic Rule  ... View more

No, unfortunately, there is no easy way to specify how many times you want the pattern to repeat. You would have to calculate the length of the last part and put that in the split. OR You would have to write it recursively to keep splitting until the desired count is reached. ... View more

Yes, it is possible to split floors into rooms. Just like you divide a mass into floors using a split in the y direction, you can divide a floor into rooms using splits in the x and z directions.  With these splits, you can specify dimensions in the x and z directions. split Operation  If you want to divide the floors into spaces with equal areas or into spaces with defined areas (i.e. one room with 70% of the area and another with 30% of the area), then you can use the splitArea() function. splitArea Operation  From a 2D footprint of the floor (instead of 3D - from 3D just use a comp to get the bottom 2D face), shapeO, shapeL, and shapeU, offset, setback, and innerRectangle operations may also be useful.  These can help you divide the space into spaces with a particular shape. shapeL, shapeU, shapeO operations  offset Operation  setback Operation  innerRectangle Operation  ... View more

For the GDB export, I actually meant to export only the 2D shapes underneath the buildings and not the full building models.  To do this, set the export option Export Features = Shapes. Then, you can apply a rule to these 2D shapes which extrudes them to the building height. I think there is a misunderstanding of what the numbers mean in the Vertices section in the Inspector.  These are the vertices of the initial shape (Rule-Based Modeling (CGA Shape Grammar) ).  The y values that you see in the Inspector are in world coordinates, or the CityEngine coordinate system.  In your example, the vertices in this section are the vertices of the initial shape onto which the building rule was applied.  Any geometry created by the rule will not be in this vertex list.  This means that the tallest point of the building is not in this list since the building is created by the rule; the building is a model. In one screenshot (with the yellow and red arrows), you converted the building models into shapes and then tried to move the vertices to increase the height of the building.  This changed the vertices of the shapes.  The rule applied to these shapes seemed to just stretch the facade texture to fit the new shape.  I do not recommend converting to shapes and changing the building height by changing the values in the Vertices section in the Inspector. Instead, I would recommend writing a rule that is applied to a 2D shape (e.g. building footprint).  This rule would extrude the shape to the building height.  If the building height is an attribute, you can change this value for each shape. attr height = 10 Lot -->      extrude(height)‍‍‍‍      print("height = " + scope.sy)‍‍‍‍‍ If you wanted to split one lot (2D initial shape) into three separate building footprints, you could manually do this with the Polygonal Shape Creation tool.  Then, you could apply the rule to each of these footprints. In other screenshots (where the y values of the vertices are about 0.02 and the printed scope.elevation is 0.22), the y values are the y values of the vertices of the initial shape in world coordinates, and the scope.elevation value is the y value in world coordinates of the current geometry created in the rule.  In the rule, there is a translate operation which translates the geometry in the y direction by the amount Street_Modern_Standard.SidewalkHeight, which equals 0.2.  Therefore, the scope.elevation value after this translation operation is going to be the initial shape's y value + the translation amount which is 0.02 + 0.2 = 0.22.  This is why scope.elevation = 0.22.  In the screenshot, scope.sy is almost zero because the geometry at that point in the rule is nearly planar or flat. Printing scope.sy after the extrude operation should give you the height of the building. This should also explain that in one of the screenshots (where y = 23.907), the y value here is not the height of the building but rather the y value of the initial shape + the height of the building.  Remember that in this screenshot, the building model was converted to a shape, and that's why the vertices appear in the Vertices section in the Inspector. ... View more

Save Snapshot is available in the Bookmarks menu (drop down next to star icon in viewport toolbar).  It takes a snapshot with dimensions w x h (defined in dialog) where w matches the width of the viewport.  The vertical amount of the viewport captured is determined by the specified aspect ratio.  Snapshots can also be controlled in Python scripts. Viewing Modes and Display Settings  Alternatively, you can export your scene and import it into other software that can produce high quality renderings. http://desktop.arcgis.com/en/cityengine/latest/tutorials/tutorial-19-vfx-workflows-with-alembic.htm ... View more

I'm not sure why the numbers are incorrect.  I've created a simple example in which I applied the following rule to two buildings.  I selected both buildings and exported them to a single spk using "One Feature Per Leaf Shape", uploaded the spk to my agol account, and published it as a scene layer.  In the scene viewer, when clicking on a floor of either building, a popup window displays the floor number and the area of the floor.  In CityEngine, I printed the floor areas of each floor, and the numbers in the Console match the numbers in the Scene Viewer.  Does this code also work for you? attr height = 20 attr floor_height = 4 Lot -->      extrude(height)      split(y) { ~floor_height: Floor }*       Floor -->      s(scope.sx - 0.5*scope.sx*split.index/split.total, '1, scope.sz - 0.5*scope.sz*split.index/split.total)      center(xz)      report("Floor Number", split.index+1)      report("Floor Area", geometry.area(bottom))      print(split.index+1 + ":\t" + geometry.area(bottom)) ‍‍‍‍‍‍‍‍‍‍‍‍‍ Here are some other notes that might help: * When changing the height of my building in CityEngine, I needed to make sure the models were regenerated, export the spk again, upload the spk again, delete the old published scene layer, and publish the new spk again.  The scene layer did not automatically update.  I needed to delete the old one first and then publish again. * Rule attributes and object attributes (as seen in the Inspector) are not exported to the spk.  Only values that are reported in the code are exported. ... View more

Maybe there are export options that could help get the desired numbers? There is an export option Feature Granularity that has two options: * One Feature Per Shape * One Feature Per Leaf Shape Imagine that you have initial 2D shape for the building footprint onto which you apply a rule that creates buildings with floors.  On each floor, the area of that floor is reported.  The first option will export one report for each building that is the sum of the floor areas of the building (GFA).  The second option lets you export a report per leaf shape.  If the floors are the leaf shapes, the area of each floor is reported separately for each floor, so if you click on the third floor, the popup will tell you the area of the third floor.  If you click on the seventh floor, then you'll get the area for the seventh floor.  The numbers you see in the popup depend on the export options and also on how you set up your reports in the rules. Esri Scene Layer Package (spk) Export  ... View more

No, generally, it's not possible to link information between layers using rules (when there are rules in both layers). In specific cases, it is possible to pass information between layers.  For example, if you have information that is not generated by rules, then you can connect rule attributes to other attributes from other layers (Inspector -> click on drop down next to attribute -> Connect Attribute).  If you have an image/map that shows distances to public transportation stops, for example, then you can connect a rule attribute to this map and get the distance to public transport.  This is similar to what is done with building heights in Tutorial 3, section Control the Skyline. Tutorial 3: Map control—CityEngine Tutorials | ArcGIS Desktop  If you have a rule that calculates the total GFA in layer B, then a two-pass approach would be needed to get that information into the rules applied to shapes in layer A.  I don't think there's a nice solution to this problem yet.  I think maybe others might use Python to help with the two pass generation (?). We are working on methods that might help with calculating distances to other shapes, so hopefully this will be possible in the future. ... View more