Using AC Python Modules in Grasshopper (IronPython 2.7)

[JSN]

Hey,

This topic is actually a bit specific and maybe not totally new but I will give it another try as I am currently always coming back to it again. So afaik Grasshopper is using IronPython which is limited to version 2.7 and the Archicad module cannot be used. Due to the fact that the GH Livebridge is lacking some basic functionalities in terms of usability I have decided to use the Python Wrapper for the JSON Interface to implement some automation features. (e.g. Automatically setting classifications for elements based on Property Information).

However, it would be better to have all the functionalities condensed in one place or in other words it would be very nice if we could use Grasshopper to further customize those snippets as this is way more user friendly to handle for the everyone than to fiddle with the Python scrippts. Sure I could write a GUI for it but it would be much faster and nicer if we could already use the existing setup in the GH template like drop down selection components which contain our property groups and names or the classification names.

The only thing different for the colleagues would be that they are not using standard GH components, but Python Components containing the relevant methods as components ready for use.

Anyhow at the moment I think this is not possible without workarounds that contain big efforts. Sure I could either use the JSON Interface directly but this would take lots of time to set it up and as I think i am not alone who wants such features this is not my task either. So, well probably there are also further developements planned to improve the GH Livebridge itself to make it more GH-like but the past months and years don't make me get to exciting here in my hopes.

Coming back to the actual question, is there any workaround how to achieve what I want and that may slipped trough my attention or is it just not possible at the moment (and in the future) and my best option is to built GUIs for my Python Scripts to make them more human friendly for my colleagues?

[leceta]

my bad, I obviate the conversion from python dict to json objects. Here it goes a working version (checked)

code from "Step 3" (see image below)

import json
import urllib2

guid = json.dumps(classSysGuid)

if run:
    req = urllib2.Request('http://localhost:19723')
    response = urllib2.urlopen(req,json.dumps({"command": "API.GetAllClassificationsInSystem","parameters":json.loads(guid)}).encode("UTF-8"))
    response = json.loads(response.read())

    classIds = []
    if response['succeeded']:
        for item in response['result']['classificationItems']:
            for key,dict in item['classificationItem'].items():
                if key == 'classificationItemId':
                    classIds.append({'classificationItemId':dict})

    guids = json.dumps(classIds)
    req = urllib2.Request('http://localhost:19723')
    response = urllib2.urlopen(req,json.dumps({
    "command":"API.GetDetailsOfClassificationItems",
    "parameters":{
        "classificationItemIds":json.loads(guids)
        }
        }).encode('UTF-8'))
    response = json.loads(response.read())
    id = []
    name = []
    description = []
    for item in  response['result']['classificationItems']:
        id.append(item['classificationItem']['id'])
        name.append(item['classificationItem']['name'])
        description.append(item['classificationItem']['description'])

Also sharing the GH file. Note that there is a dependency to a 3rd. party plugin (Human), but Its not necessary for the json logic to work, just used as a convenient UI gadget to select between different classification systems received from Archicad document. There is alternative implemented in the shared gh if you don't want to install Human in your system.

[JSN]

Ah yes thx the hint how to convert the dicts to json objects again helps a lot to understand the parsing.
I used it to reformat my guidList (which had no hierachy) to retrieve the ClassificationDetails for all ClassificationItems. So yeah, I will look a bit more into that next week if time allows it. I will come back to you if I encounter the next hurdle 😉

[poco2013]

Hey JSN:

I have been following your posts and am curious as to your intended use of Grasshopper? I see that there was some initial complaint about the slowness of the script. I didn't see any significant difference other than the initial requests time delays. Also, to that point, since the initial request of GetCllasifcationItems returns all the info you are asking -- why then call GetDetails? Also don't see a need for the double conversion of JSON commands?
Finally, Since the script will work just as well within Archicad, any IDE, or Grasshopper, allowing for the change in urllib2 from 2.7 to 3.0+, what is the advantage of Grasshopper? What are you ultimately trying to accomplish that can't be directly done in Archicad or the Archhicad/Grasshopper interface? -- Just asking?

To illustrate my point I have attached a Python Grasshopper script that returns the classifications info with minimal delay.Runs equally well within Archicad -- just change urlib2 to urllib - change from 2.7 to 3.0+

 #import rhinoscriptsyntax as rs
import json
import  urllib2 as rb

#request = rb.Request('http://localhost:19723')
request = 'http://localhost:19723'

response = rb.urlopen(request,json.dumps({"command":"API.GetAllClassificationSystems"}).encode('UTF-8'))
results = json.loads(response.read())
result = results['result']['classificationSystems'][1]['classificationSystemId']['guid']
response.close()

response = rb.urlopen(request,json.dumps({"command":"API.GetAllClassificationsInSystem",
"parameters": {"classificationSystemId": {"guid": result }}}).encode('UTF-8'))
results = json.loads(response.read())
response.close()
seed =results['result']['classificationItems']

output = []
level = 0
def get_ids(seed,kids = 0 ):
    global level
    level += 1
    for item in seed:
        output.append( '   '*(level-1) +  item['classificationItem']['id'])
        if kids >0:
            kids -= 1
        
        if 'children' in item['classificationItem'].keys():
            depth = len(item['classificationItem']['children'])
            get_ids(item['classificationItem']['children'], kids = depth)
        else:
            if kids == 0:
                pass # Debug only
    level -= 1
    
get_ids(seed, kids = 0 )
for x in output:
        print(x)

 

[leceta]

Even if I have not been asked, let me share my point of view
I personally find interesting the idea of having packed all this tech in the same environment. I found the current state of things... "disgregated". Param-O should be the natural place for all this to happen, but no tinkering possible currently without C++ (afaik). Limited connection with GDL code, no python interface, no GH interface... Sadly, Graphisoft doesn't seem interested in "agglutination", but hopefully time will demonstrate I'm wrong.

With all its performance/stability issues, I think GH connection is currently the most accessible "all-this-tech agglutination" tool, it offers a more powerful interface to couple with GDL code and all the JSON API is there using IronPython, plus the plethora of goodies that offer GH...

Also don't see a need for the double conversion of JSON commands

cool, much better!

[JSN]

Hey Gerry,

As leceta already summed it in well wrapped sentences, it's an attempt to unite the fragmented situation we are facing at the moment. There have been discussions in other topics that it is a very welcomed way to open up different interfaces and ways to connect but currently it feels like you need always a different tool for a different workflow task. This makes it very hard to setup a streamlined developement pipeline. Grasshopper is not only very easy to learn and intuitive to use, but it allows you to achieve very fast results. With all it's universal goodies it's simply the weapon of choice.

Anyhow after some time I can say that the JSON API approach with IronPython has kinda served as a proof of concept, it could indeed be used to compensate what the official GH plugin is lacking since the beginning - the possibility to alter existing elements e.g. here more specifically to change classifications based on element property values (but dynamically). Needless to say that it is of course lots of tinkering around. I mean you could write it very use case specific all within one component - as you did very efficiently - or with the more universal building block approach as I did, to have more flexibility. So, well as I said it works and I think there is still some space left for improvements but at the moment I am fine with the speed. Especially because the functionalities are kinda limited at the moment.

So let's hope that the JSON Api will be extended further in the future to be able to automate more and more. Needless to say that it would be of course highly appreciated to see Param-o grow but I think it is a long way to go to reach anywhere near because with the grasshopper experience the bar is set very high ...

[poco2013]

Thanx for the feedback Leceta and JSN:

I mostly agree but getting there is the real problem in my opinion. With the introduction of Python, Param-o ,Grasshopper, MEP, Structural connections, etc., etc. I expect that Graphisoft has taken on more than they can deliver. Small yearly incremental changes in each of these areas will be of no use to anyone. For example, the Present C++ API has approx. 900 functions, The present Python API has 25. At this rate, it would be 50 years before Python would approximate the utility of the C API. and the same is true for the other features.

With respect to Python, Graphisoft's management has already reneged on several promised developments. I do wonder if the small increments and diverse approach is just marketing hype to to tout features that really have little real world utilization because of the limited development effort. In effect, false advertising?

The approach of "lets do a little of everything" will not work and never has. It only promotes features that can not be practically used.This is ultimately going to frustrate users and give Archicad a very bad reputation if some change in philosophy is not demonstrated soon.

[JSN]

poco2013 wrote:
Graphisoft's management has already reneged on several promised developments. I do wonder if the small increments and diverse approach is just marketing hype to to tout features that really have little real world utilization because of the limited development effort. In effect, false advertising?

The approach of "lets do a little of everything" will not work and never has. It only promotes features that can not be practically used.This is ultimately going to frustrate users and give Archicad a very bad reputation if some change in philosophy is not demonstrated soon.

I am afraid that your assumption is reflecting pretty well what many users already having in their minds ...

[leceta]

I mostly agree but getting there is the real problem in my opinion. With the introduction of Python, Param-o ,Grasshopper, MEP, Structural connections, etc., etc. I expect that Graphisoft has taken on more than they can deliver. Small yearly incremental changes in each of these areas will be of no use to anyone. For example, the Present C++ API has approx. 900 functions, The present Python API has 25. At this rate, it would be 50 years before Python would approximate the utility of the C API. and the same is true for the other features.

With respect to Python, Graphisoft's management has already reneged on several promised developments. I do wonder if the small increments and diverse approach is just marketing hype to to tout features that really have little real-world utilization because of the limited development effort. In effect, false advertising?

Yes, as JSN said this is a shared "fear". Graphisoft seems to follow the same pattern, again and again, letting perish lots of great initiatives, but feel bored complaining about all this. The general user complacency, the minimal near to zero contact with ArchiCAD developers... makes the conversation not only boring (because its futility), but also discouraging because one finishes feeling like an annoying troll.

So, fingers crossed, let's see how good they do it this time.