Latest Contributions by CherylLau

It's not possible to import an rpk directly into a cga rule.  RPKs can be created with or without the cga source code included.  If the rpk has the cga source included, then you can unzip the rpk (like any other zip file) to access the cga files, and the cga files could be imported into other cga files.  If the cga source is not included, then you can't import the rpk into another cga file.   As Brian mentioned, some park-like cga rules could be found in some of the downloadable examples such as Redlands Redevelopment or Planning 04 Landscape Design (Help -> Download Tutorials and Examples). ... View more

I'm not sure I understand what you wrote.   However, from the image, I'm guessing that you want the magenta building on the right to only have a setback on the side where the cyan road is (let's call this the front edge) and not have any setbacks on any other edge (let's call these the side and back edges).  The image shows that there are setbacks on the side edges, and I think you probably don't want these setbacks to be there.   The reason why the setbacks appear on the side edges is because for each of the side edges, the minimum distance to the cyan road shape is less than your threshold.  This is because minimumDistance uses Euclidean distances in entire world coordinate system (meaning, all 3 axes/directions xyz are involved).  In 3D space, the scope of a side edge is still really close to the scope of the cyan road; the distance between the scopes is less than your threshold of 1m.   What you probably want is to limit minimumDistance to only look for shapes in front of the edge along the direction of the edge normal.  Unfortunately, we don't have a directional parameter for this in minimumDistance yet, and sorry, I'm not sure what workaround you could use. ... View more

Brian is right, using valuesAttr in an Enum is the way to do this.  You don't necessarily need a csv file if you want to hard code it, but maybe the csv file makes it easier for you to extend.  It depends on your needs. Here's a simple version with hard coded values in a case statement. @Enum("A", "B", "C") attr type = "A" @Enum(valuesAttr=subtypeValues) attr subtype = subtypeValues[0] @Hidden attr subtypeValues = case type=="A": ["A1", "A2", "A3"] case type=="B": ["B1", "B2", "B3"] else: ["C1", "C2", "C3"]   Instead of a case statement, you could also make it more extendable for the future, for example, by putting all the possible subtype values in an array and then creating the subtypeValues array by only choosing those values from the big list that begin with type.  Again, not sure this strategy would work for you; it depends what values you have and what your needs are. ... View more

This is actually not a bug.  Whitespace inside the searchQuery string in fileSearch/filesSearch indicates AND in the query.  Using whitespace, two or more queries can be AND-ed.  See the last example in the doc. https://doc.arcgis.com/en/cityengine/latest/cga/cga-file-search-function.htm The same applies to other functions which use fileSearch:  assetApproxRatio, assetApproxSize, assetBestRatio, assetBestSize, assetFitSize, fileRandom, imageApproxRatio, imageBestRatio In order to put whitespace into a filepath, use single quotes:   filesSearch("'Wall Textures/*.png'")     Alternatively, the escape characters \s and \x20 also work to replace a space.  Note that an extra backslash is needed so the cga compiler interprets it correctly (instead of as a normal backslash).   filesSearch("Wall\\sTextures/*.png") filesSearch("Wall\\x20Textures/*.png")     ... View more

Another way would be similar to how the facade and windows are textured in Tutorial 6. https://doc.arcgis.com/en/cityengine/latest/tutorials/tutorial-6-basic-shape-grammar.htm The idea is that the UVs are setup across the whole facade when the facade is created using setupProjection().  Then, the rule goes on to break up the facade into walls and windows.  On the wall pieces, the texture is assigned using texture(), and the UVs are projected onto the shape using projectUV().  On the window pieces, you can either insert geometry that already has UVs in which case those UVs will be used, or you can insert a primitiveQuad() which automatically has UVs on it, or you can assign UVs to the window shape using setupProjection().  Here's a simplified version of what Tutorial 6 does. Lot --> extrude(height) comp(f) { front: Facade } Facade --> setupProjection(0, scope.xy, 1.5, 1) // setup 1.5m x 1m texture tiles across whole facade split(y) { ~floor_height: Floor }* Floor --> split(x) { ~tile_width: Tile }* Tile --> split(x) { ~1: Wall | window_width: split(y) { ~1: Wall | window_height: Window | ~1: Wall } | ~1: Wall } Wall --> texture(wall_tex) projectUV(0) Window --> i(window_asset) // uses UVs on inserted asset texture(randomWindowTexture) // alternative window option Window2 --> primitiveQuad // has UVs that stretch across quad texture(randomWindowTexture) // alternative window option Window3 --> setupProjection(0, scope.xy, '1, '1) // define UVs that stretch across scope of shape texture(randomWindowTexture) projectUV(0)     ... View more

I can't seem to reproduce your problem.  The occlusion part of your tree code above works for me if I test it against a simple extruded shape created by another rule.  Note that the sphere is being tested against the building when the sphere is on the ground level (which maybe you intended).  Would it be possible to attach a scene file where you encounter the problem? ... View more

There is a tutorial about importing data from a CSV file. Tutorial 21: CSV import—ArcGIS CityEngine Resources | Documentation  This rule that makes legends is another example that uses arrays and CSV files. https://www.maps.arcgis.com/home/item.html?id=834f71b286634b7db92e15bdc22ec431  ... View more

As I understand it, I think you want to make a cylindrical pipe that connects all the points you have. A single pipe could be done nicely on a street network using insertAlongUV().  Save a cylindrical asset in a file, and then insert that cylinder so that it follows the UVs of the street shapes.  Note:  If you have intersecting pipes, then the intersection point won't be nice.  But, in your case, you only have a single pipe, so it should be ok. insertAlongUV operation—ArcGIS CityEngine Resources | Documentation  You can also try applying the Fence_On_Graph.cga rule in ESRI.lib to street shapes from a street network.  If you disable everything except the base (hasPosts, hasHorizBars, hasVertBars, hasUpper) and set the baseMiddle_asset to your cylinder, then you'll get a cylindrical pipe that follows the streets. As another example, you can look at how this guard rail was inserted using insertAlongUV() so that it follows the street. https://www.arcgis.com/home/item.html?id=3bb75a133c3e4ceb98607d0423b1f3ec  ... View more

From what I read, I think you want the texture on the first floor to be the same as the texture on the second floor.  When LOD=2, this is not always the case.  Here is why. For example, when BldgHeight=4 (default value) and LOD=2, the first floor is textured in the rule ResWallWindow with the texture RandomFacadeTextureRES, and the second floor is textured in the rule ResWallNoWindow with the texture RandomFacadeTextureRES_NoWindow.  The first and second floors, therefore, have different textures in this case. Tip:  You can use the Model Hierarchy (Window -> Model Hierarchy -> Inspect Model) to see which piece of code generates a certain part of the model.  Click on a part of the model in the viewport, and its corresponding node will be highlighted in the Model Hierarchy.  Double click on that node to go to its corresponding rule in the cga code. This screenshot of your rule applied to a footprint shows what I mean by first (pink) and second (blue) floors.  The lowest floor is the underground (basement) part of your rule. With regards to the roof problem you mentioned, I'm not sure what you want to happen with the roof. ... View more

Here's another idea: Create an attribute terrainElevation and connect it to the terrain's elevation:  Click on the drop down box next to the attribute in the Inspector -> Connect attribute -> Layer attribute -> Terrain Imagery -> elevation.  This sets the attribute value to the terrain's elevation below the scope origin of the initial shape.  The following rule extrudes upwards in the world.up direction and then translates the building down to the terrain.  Note: This will be an approximation only because the attribute can only get the terrain elevation under the initial shape's origin.  The building might not align to the terrain exactly. attr terrainElevation = 0 attr distToTerrain = 0 RoofMass --> set(distToTerrain, scope.elevation - terrainElevation) comp(f) { bottom= RoofFootprint } RoofFootprint --> extrude(world.up, distToTerrain) t(0, -distToTerrain, 0)‍‍‍‍‍‍‍‍‍‍ ... View more

I would have recommended using comp to get the bottom face of the roof and then extruding downwards the height of the building.  Note that since I assume the bottom face has a normal pointing towards the ground, the extrude is in the positive direction. const building_height = 10 RoofMass --> comp(f) { bottom= RoofFootprint } RoofFootprint --> extrude(building_height)‍‍‍‍‍‍‍‍‍‍‍‍ What doesn't work for you when you extrude downwards?  Does the bottom face not point towards the ground? It's also possible to extrude upwards in the world.up direction and translate everything down.  (Note: reverseNormals would help to switch the direction of the face normal.) extrude operation—ArcGIS CityEngine Resources | Documentation  Alternatively, you could also extract the RoofFootprint, convert the footprints to shapes (Shapes -> Convert Models to Shapes), align them to the terrain (Align Shapes to Terrain icon in toolbar), and extrude upwards the building height.  If the height doesn't match, things get more complicated.  In this case, some tricks like using a python script to write the scope.elevation to an object attribute might be useful.  Or, using minimumDistance with IDs for each roof in the label might be useful. ... View more