topic Re: Hierarchy, linking different cga files. in ArcGIS CityEngine Questions

Hierarchy, linking different cga files.

KristianMortensen1 — Mon, 31 Oct 2016 12:14:29 GMT

Hello All.

I'm currently working on a way to create a CGA rule file which can generate many different buildings within a short period of time. The goal is to create a rulefile which lets the designer investigate multiple designs without having to redraw his/her project every time. I'm working with the assumption that a design of a building plan consists of three parts, the distributions of the building footprints (bldgFootprints), the envelope (bldgEnvelope) and a facade (bldgFacade).

The goal is to have a main cga rule file, which link to a rule file that draws the bldgFootprints. This file then link to a file which draw the bldgEnvelope, and finally, the bldgEnvelope links to a cga file which draw the bldgFacade.

To avoid having to write all of the different "types" of building footprints in one rule file, I would like the bldgFootprint to link to other rule files, and by using a drop-down menu choose between them. Se diagram below.

By using this structure, it would be possible to write a new CGA file for a specific building footprint, and then add that to the overall structure simply by naming the instances within sub-rule file the right names. It would also eliminate the need for writing one very long cga file which can generate all possible building footprints. By using this structure it would be possible to make the "Database" bigger and bigger over time by adding more and more bldgFootprints0X to the project. So the first question, does this seems as a relevant way to do it, it will end up with a very very big amount of rule files and some of them will maybe have the ability to do the exact same thing but on the other hand it allows the designer to create an individual script and add it to the overall structure.

The next question is, I simply can't get it to work, I have managed to link the main file with the bldgFootprint, link that to bldgFootprint0X, link those to bldgEnvelope, but the attributes which is located in bldgEnvelope is not visible in the inspector.

It looks like it is only possibly to have three layers of linked files visible in the inspector, so my "main" can link to "bldgFootprint" which can link to "bldgFootprint0X" and all the attributes show up, but when the "bldgFootprint0X" links to "bldgEnvelope" the attributes for envelope does not show up..

I'm looking for all the help and thoughts I can get on the subject, does any of you have relevant experiences with this type of project, can you see a more simple path through. Am I on the right track or is it just stupid? If anybody has an interest in the project and which to follow it more, you are welcome to send a message to me.

Re: Hierarchy, linking different cga files.

CherylLau — Mon, 31 Oct 2016 13:48:37 GMT

What version are you using? There was a bug in 2016.0 (and possibly earlier) with attribute passing on second level imports, and it may or may not be related to this. This should be fixed in 2016.1 though.

Re: Hierarchy, linking different cga files.

KristianMortensen1 — Mon, 31 Oct 2016 14:01:49 GMT

I'm using 2015.2 at the moment.

can you elaborate on "passing on second level"?

Re: Hierarchy, linking different cga files.

CherylLau — Tue, 01 Nov 2016 10:00:54 GMT

If you have an attribute in the parent class, you can "pass" it to the child class (this actually happens by default unless you tell it not to). Sorry, "passing" is not the right word here. If an attribute x is defined in the parent class (attr x = 10), and the child class also has an attribute x (attr x = 20), then the parent's value will overwrite the child's value unless you tell it not to overwrite it, and the value will be 10. The details can be found here:

import

I would recommend upgrading to 2016.1 especially when using imports since several issues were fixed regarding imports and attribute propagation.

CGA Changelog

Re: Hierarchy, linking different cga files.

KristianMortensen1 — Thu, 03 Nov 2016 10:05:39 GMT

Thanks for the answer, that clarified another question, but it does not seem to be the problem in this particular question, when linking the fourth rule file, which has an attribute that none of the other has, changing the value of the attribute in the script manually make changes to the scene but i can not access the attribute from the inspector.

There should be a number five level called rf_BldgEnvelope which should be a sublayer to both the rf_BldgFootprint01 and rf_bldgFootprint02. I do not know is this is possible as it would become a very complex system, but looking back on the original "system"

I want the first file to give the possibility to chose if i want waterHandling or not, then in bldgFootprint I want to be able to choose between which of the three BldgFootprint types I want, and in BldgEnvelope I want to choose between which of the three envelopes files I want and so on. So you could say I want to be able to chose which way through the "tree" I want to go and then be able to change the attributes which are linked to each step.

Re: Hierarchy, linking different cga files.

CherylLau — Fri, 04 Nov 2016 13:46:34 GMT

Creating such a hierarchy seems to work for me in 2016.1. The attribute "height" is shared between all files, and the attribute "a" is only in buildingEnvelope.cga.

Re: Hierarchy, linking different cga files.

KristianMortensen1 — Mon, 07 Nov 2016 09:31:00 GMT

Hey Cheryl.

Thanks for the answer, I think I need to update my CE then. I can see that you are able to see the attributes for all of your linked files which is not possible to me. When there is more three "layers" I simply not show up in the inspector even though I'm able to change the attributes in the CGA rule file, but I guess that this happens only in 2015.

Re: Hierarchy, linking different cga files.

DevinLavigne — Tue, 01 Sep 2020 23:29:03 GMT

I think this bug has resurfaced. Updated linked CGA files aren't "refreshing" in the master file.

Re: Hierarchy, linking different cga files.

CherylLau — Wed, 02 Sep 2020 09:20:12 GMT

Thanks, Devin. There might be a refresh problem. Do you have more details on when and what things are not being refreshed? Do you have an example?

Re: Hierarchy, linking different cga files.

DevinLavigne — Sun, 12 Dec 2021 16:39:20 GMT

I've created a rule that subdivides land and then passes the "pad" to a master rule that builds the structure. All of that works fine. If I modify the master_structure rule everything refreshes fine.

Subdivide.cga --> master_structure.cga

The problem I'm encountering is that I've created a master rule to create PBR textures from a library and other master rules that create doors and windows. When those rules are modified (so a reference within a reference if you will) they do not refresh. I have to make some revision to the master_structurerule to get CityEngine to "see" revisions to 3rd tier references.

Subdivide.cga --> master_structure.cga --> master_texture.cga
                                       --> master_doors.cga
                                       --> master_windows.cga

And if I just draw a shape and apply master_structure to it, I can edit its references with expected behavior - its the third level of reference where its breaking or not triggering a compile of the new cga. Does this make sense? I can screenshare with you if you'd like.

Re: Hierarchy, linking different cga files.

CherylLau — Mon, 14 Sep 2020 12:59:57 GMT

I tried to recreate your structure with Subdivide.cga, master_structure.cga, and master_texture.cga. I have a shape that has the Subdivide.cga rule applied to it. Then, I tried to modify master_texture.cga, (for example by changing the value of an attr in the cga file or adding a rotation to the rule), and it works for me (the model is correctly regenerated with the changes).

We are aware that there are cgb refresh problems (and I've noted your issue), but without an exact repro, it will be hard to fix. If you are willing to share more insights, we'd be grateful, and you could write to me privately instead if you'd be willing to privately share some code.