Latest Contributions by DavidWasserman

Yes I did. I actually was not interested in elevation data in this particular case.  I ultimately got it work by dropping resolution to 1 K I think. It could be a limitation of the zoom level I was at? Have you ever had issues with really zoomed in extractions before?  ... View more

Are you looking at the floors from above or below? Both? It could be a face culling issue.  What happen in the CE scene when you toggle Back face culling on and off?  http://cehelp.esri.com/help/index.jsp?topic=/com.procedural.cityengine.help/html/manual/ui/vw/vmodes_dsettings.html  ... View more

It randomizes based on the %. To get it to choose each one with the same likelihood, they need the same %. The listRandom() approach unlike the % case-else structure cannot be biased in the same way I believe.  ... View more

To add to this, if you want to choose between multiple random value ranges you could use the string-list functionality combined with int/float casting (everything in CE is Float I believe). You could have a string list as an input in the rule parameter even if you wanted to change it in the inspector. example: attr string_list= "3;4;5" rand_value=float(listRandom(string_list)) #Returns 3 or 4 or 5 as a float.  Thomas's example is the more accepted way to do this especially if the choices are meant to be hard coded, but there are multiple ways to do same thing.    ... View more

In many cases, you may not need separate files, but just keep a well built case -else structure that makes the breakpoints in style divergence clear. You do need to code each style you want to represent however, and fine a way to tie them back to your lot files whether it is random assignment or attribute driven. Generally, you can create a valid scene at the scale you are talking about by just grabbing the top 3 styles and developing rule parameter options for them. If you want to go the multiple rule file approach to keep it separated, as most buildings share some common massing elements, it is possible use one rule as a library for the others. Essentially any code you see as a duplicate you just put into your library rule and call them in the style rules.  ... View more

Thanks Jonathan. Let me know if you run into any issues. 😃 ... View more

This is the exact type of application that procedural as a service would benefit from, but as far as I know our only options for procedural rules are static model displays. I am not even sure how to make sliders for example be exposed in either the CityEngine web scene or ArcGIS Pro scene environment. As far as I know, procedural outputs must be "baked" before being shared. I was hoping for something like this for a temporal visualization and had to settle for "binning" the data into hourly segments.  Theoretically you could emulate this type of behavior if all the model combinations were made before hand. I think for example you could create a range of zoning parameters in a jython script, and then use the itertools.product() function to product every feasible combination of those rule parameters, and then call those models based on a match from a users edits to that parcel...this however is not efficient and I don't even want to think about how many SPKs that would require. There are really no great solutions for interactive procedural editing over the web with a pure CityEngine/Esri stack yet. This might change or my understanding is out of date, and some one else could provide more input.  What is the company out of curiosity?  ... View more

I figured I would report back.   At some point I changed all the seeds of the streets in the scene after another reboot and I experienced no crashing behavior. I also deleted some of the older unused scenes in the project folder. For some reason or another I am not experiencing the same behavior in a 3 hour run of rule/scene edits. I am not sure if deleting some of the project meta data before helped (unused materials in the bin/rules/etc), but I did not have to delete the meta data/prt folder in the workspace. It seems like it was never an issue... ... View more

This might actually help me with some of my experiences lately, but they seemed to have resolved without deleting the prtcache/metadata folders yet.  ... View more

I also tried resetting the scene version/altering the file. It was 2015.2 believe. I am not sure if I opened it with 2016 (not 2016.1) at some point...I don't think I did. What would you suggest trying if this is the issue?  ... View more

Yeah if other parameters don't change it, then I think it is the distorted UV space on the street. I was largely just curious.  Sometimes you can't trust the UV units once a distortion happens. I sometimes create a fake inserted cube scoped to the length of the current scope and use it to provide alternate reporting (or just report scope.y/x/z etc). I have tried to develop heuristics with the geometry functions to determine if I could find out if the UV was distorted, and I did not have much success. My best advice is program CGA defensively and assume you need to build your own UV 'foundation'. If you find any useful functions that might help with detecting a UV distortion I would be interested in knowing about it. I think the challenge is that ideally that distortion could be detected globally before the rule starts to drill further into the shape hierarchy.  ... View more

Hey Devin,   As I read your rule, the street shape should be split along v 4 times, and what is even more interesting is that the dimensions are reading out correctly.  In general, in my experience Street UV Spaces are very weird. I outline some of my own challenges with them in the CS rule documentation.  In the documentation for UV Space Splits it does say the following:  Setting the splitDirectionparameter to unitSpace permits to operate directly on the surface, i.e. work in units (e.g. meters or yards). Depending on the geometry and type of parameterization there is some inherent distortion in this conversion. Borders (start, end) of the uv split are defined by the minimal and maximal values found in the selected uv coordinates. The genral syntax of the split is the same as in the cartesian case described above, i.e. relative and floating operators (' and ~) can be used as well as the repeat operator (*). Please check out the examples below. So depending on the street rule, different street rules handle this problem differently. The defaults in Esri.lib use non-unit space UV channels and some clever texturing/math to efficiently and elegantly represent the streets they are designed to represent in units of the shape parameters lane width. This however makes exact dimensions hard to make clear in edits to add things like bike lanes and parking lanes (elements that are hard to represent in terms of street "lanewidth" or in exact units generally). The uvSpace channels are the ones that are likely to not experience distortion however and they tend to be able to generalize to more street shapes than unitSpace.  The complete street rule has many functions in the front of the rule that are used to determine street widths, lane widths, and lane counts at the very beginning of the rule. The Complete Street Rule is using UV channel 0 (unitSpace) like you are in this example to keep everything in exact units, but it only starts V splits after it buffers the main center street section away from the crosswalk/intersection shape. The results you are seeing I believe are distortion from the fact you're splitting your UV space with Nodes that are set to "Smart". Keep in mind segments that lead to roundabouts or curved spaces are "distorted" UV spaces. What you will notice in the CS rule and likely other street rules is the first thing established is the split u direction UV space that establishes crosswalks (In the case of Street_Modern_Standard.cga, the UV Channels used again are not unitSpace, and are likely to not experience the same distortion you are seeing here).  This does more than create a crosswalk+stop bar buffer, it creates a buffer between distortion creating intersections and the street UV space. If you want an example of how this works, in the CS rule you can bend streets and adjust the buffer distance from the crosswalk to the stop bar. Enough distortion and the street rules ability to assess its lane allocation/street geometry just breaks down and you get a mess.  Why does this happen?  I think it is because the intersection shapes can change the minimum and maximal values of the UV texture space so that the street will make splits and other alterations in a distorted UV space (the width of the street is longer at the intersection relative to the rest of the cross-section- see Kristian's Screenshot below for a visual). In fact, the dimensions might be reading out correctly because the street is splitting it the appropriate amount when measured in UV texture space, but once the UV space is distorted what that looks like is a very different matter.  Here is the relevant section of the CS rule Documentation that discusses this issue:  A note on “Space Conflicts” The issue that comes with this though is that the UVSpace sets 1 and 2 and the unitSpace in set 0 have the potential to have “conflicts”, where generally UV Sets 1 and 2 (Crosswalks) will start eating geometry of UV Set 0 (Main Center Section). The way that this issue was mitigated was by using the space between the crosswalk and the stop bars as “filler” that could be eaten away on angled intersections (intersections that meet at an extreme obtuse or acute angle), without impacting how the street rule functioned. Something to be clear about is that if the crosswalk UVs eat too much geometry, the way the street calculates width and other aspects of the rule might change (harming overall function and stability of the rule). Thus, it might help to increase the spacing between the stop bars and the crosswalk at weird intersections. In most cases though, this problem is something the user does not have to worry about, especially if they are concerned with mainly cross sections. The solution is to create a crosswalk space or 'buffer' from the intersection or to use only intersections with the cross shape. When I used your code on a different node I got the expected result.  Getting curved streets right is hard based on what I have heard from ESRI CE team. I have frequently described street rules creation as programming on shifting sand. The interactions of the street UVs with other shapes/intersections play a very large role in this. For rule development it always helps to develop rules on a street shape connected to crossings, then try to break the rule on different street shape. Sorry for the essay, this question is one I revisit from time to time.  ... View more

Thanks for catching the Toolbox issue. Glad it works perfectly. Let me know if you get any other ideas for the tool. 😃 ... View more