Import CGA rule from different CityEngine project

[KristianMortensen1]

Hello

I'm trying to create a CityEngine project where I want to add a facade to a building.

I have created the "Facade.cga" rulefile in a project called "Urb-Day" and now I want to use the same "Facade.cga" rule in another project called "stormwater".

I have tried to use the: import F_Facade: "Facade.cga" in the "Stormwater" project, and it works if the "Facade.cga" rulefile is located in the project "stormwater", but I would prefer that "Facade.cga" could be accessed when it is still placed in the "Urb-Day" project.  

I think it is just the path to the facade.cga rulefile that is wrong, any suggestions? 

[KristianMortensen1]

Thanks for that answer, then I will just have to adjust to workflow i had imagined. 

[MatthiasBuehler2]

Hi all,

I'm adding a few more inputs to this. The answer provided is not completely correct.

CGA does support absolute paths and it is actually explicitly designed to do so. As the original post states, it's the goal to import CGA rules from OTHER PROJECTS.

Library projects such as the ESRI.lib are specifically there to provide rules that can be referenced and not as a resource for copy-pasting into every single project!

When doing absolute file paths, make sure you use the correct formatting:

/ProjectName/...

The first forward slash is the 'workspace root', short for 'workspace'. It is mandatory an absolute path starts with this slash.

CGA's drag and drop functionality should automatically create the correct paths. E.g. drag and drop a plant rule file from the ESRI.lib into your own CGA source code and check the line of code that is created for the 'import' statement.

Note why using this is very important:

Many CityEngine projects use the same assets, such as e.g. the plants. So copy-pasting all plants and street rules into every project we work with is a waste of space and makes versioning and project download times a nightmare.

Please push the 'library nature' of CityEngine, this is reason why both the ce.lib and the Esri.lib default projects are there.

Cheers!

Matt

matthias buehler || dipl. arch. eth zurich
------------------------------------------------------------------------------------------------------------------
vrbn bühler || www.vrbn.io || winterthurerstrasse 51 || 8610 uster || switzerland
+41 78 930 04 07 || matthias.buehler@vrbn.io || @vrbnio @mattb3d

[DavidWasserman]

Hey Matthias,

As I reread the question, this is the far superior answer as it achieves the expected goal. Kristian, when I gave my answer I realized it sounded like I precluded the ability to import rules from other projects because I stated you should move the assets folder if you want to create a self contained project (I only suggested that because sometimes it is easy to forget). Please follow the instructions Matthias provide on importing rules with relative paths to other projects. I will say relative paths from the project folder are at least best practice, with common references in the documentation for some path functions * for asset paths. 

That said, I think Matthias might have to clarify absolute paths in CityEngine. 
Matthias, when I try the following for the lanes folder (All Forward Slash because \ common to windows is not recognized), the rule does not seem to find assets paths when they are absolute. This is the case if I put "/C:" or C: is removed along with other path components past CE install workspace as well. 
*Edit: Based on the response below, using an absolute path based on the computer's root directory will never work in CityEngine. 

*Edit: In CityEngine the example below would be an absolute path because it is relative to the CityEngine root directory. I previously mentioned it as a relative path. 
-Absolute Paths- relative to CE Root directory and is project name dependent, if used for modular referencing it is assumed the project exists and its name space won't change. Have a / in front of them. This is how Esri.lib works for example. 
EX: /Complete_Street_Rule/assets/....

-Relative Paths- relative to the project folder's rule directory. 
- EX "Complete_Streets"

Is there a correct way to use absolute paths in CGA? Can you elaborate?

David

[MatthiasBuehler2]

Hi,

• 'Absolute paths' in CGA  are always absolute to the workspace root, never the windows drive (e.g. C)
• 'Relative paths' in CGA are always relative to the project.

==>

Anything starting at the workspace root with a forward slash and the project name is an 'absolute path' within CityEngine, as CGA does not 'know' anything outside of the workspace.

Examples:

• Referencing a rule from an other project:

         "/Otherproject/rules/targetRule.cga"  (= absolute path)

• Referencing a rule from current project:

         "rules/targetRule.cga"   (= relative path. Note it is important not to have a '/' at the beginning, as CE would search for a          project that is called 'rules'.)

Notes:

- I'd always avoid to reference assets from other projects with absolute paths (as project name changes force many rule changes).

- If you have absolute paths for rule imports in a projects, it's implied that specific other projects need to exist in the workspace. This is ok, as it allows modular project references.

- Note that CE has a heuristic that adapts the import statements if you change CGA rule names. This does not happen with project name changes.

Hope this helps!

Matt

------------------------------------------------------------------------------------------------------------------
matthias buehler || dipl. arch. eth zurich
------------------------------------------------------------------------------------------------------------------
vrbn bühler || www.vrbn.io || winterthurerstrasse 51 || 8610 uster || switzerland
+41 78 930 04 07 || matthias.buehler@vrbn.io || @vrbnio @mattb3d

[DavidWasserman]

Thanks for clarifying the definition. So absolute paths in CE are those relative to the CityEngine workspace, and relative being to the working project rule directory. For most programming languages, I guess the confusion is that the master root directory is starting from a  higher level root (C/Drive Name).
Thanks for correcting me Matthias. 

[timrobinson]

Hi Matt,

That advice about the Library functions is gold dust!

However, I've never come across this explained in any detail. It's certainly not in the Help File, and I can't find anything on the ESRI site, or recall anything on the old Procedural site that ever went over this.

It would be really good to know how the .lib spaces work. All I know is that ESRI.lib pops up in each workspace, and I had assumed that it was a behind-the-scenes mechanism not to be touched. For example, how can corporate teams set up a template project structure, or ensure that any new workspace includes corporate library files? I had not noticed any example rule files referencing the ESRI.lib, so had no idea that this could be done.

Any ESRI staff - can we get some further explanation on all of this please?

[DavidWasserman]

Hey Tim, 

The Complete Street Rule and some of the Rules in the Redland's Example reference Esri.lib assuming it will be available as a constant path in the CityEngine work space (chosen on installation). It is most common that the rule examples take the tree loader rule from Esri.lib for example. 

Line Example:

import Tree : "/ESRI.lib/rules/Plants/Plant_Loader.cga" # Taken from ESRI.lib and uses its assets. Keep this in mind when using rule.

David

[timrobinson]

Hi David,

Thanks for the reply! I guess I've just not noticed the presence of those lines in the Redlands or Complete Streets rules.

It would still be good to get an explanation as to the ins and outs of modifying the ESRI.lib or ce.lib content. Is it even advised?!

From Matt's reply above I get the idea that the lib content is encouraged to be used as a tool to avoid repeated copying in of resources - but what if we want to use more than just the very limited set of data in ESRI.lib for example? I'm just now aware of how to go about structuring such a resource tool, would be great to get some guidance from ESRI.

[DavidWasserman]

Hey Tim, 

Esri.lib does have all the default plant and some of the basic street rules that ESRI provides with it. The  Esri.lib libraries likely have nothing stopping from having other rules and their assets added to their project folders for import and use in other projects. Edit*- Based on Matthias's answer below, while you might be able to use the libraries this way, these are low level libraries that get replaced on start up if they are not found. It would likely be best to make personal library like Tims_Library or something like that.  Any change to the interface or folder structure of Esri.lib or ce.lib is not recommended as it could break the paths that a lot of rules depend on. 
While I agree with Matthias's approach for managing CityEngine projects generally, if you need to share projects or distribute them, it makes sense to keep the assets of the rules you are using in the current project folder (UNLESS they come with CityEngine on install such as those in Esri.lib, in which call Esri.lib as the library it is intended). For example, for the complete street rule to be properly distributed, it requires its assets in the project so others can use it, but it does not require the plant's assets and rules because it expects the Esri.lib interface not to change (until it does, then I have work to do). 

David