Differing rooms names Rhino->Grasshopper

Hi! I’m working with a model where having names redundant in rhino is intentional, as I’ve got a re-naming script to apply a naming convention.
Though the rhino display names are differing from the grasshopper display names as seen below


The script in the ghpy comp is a simple

a = [room.display_name for room in _model.rooms]

I’m assuming since there are duplicate display names, that PO is using the room identifiers?


(bottom two zones in room.identifier are rooms I made and didnt change the ID)

The desired functionality is the display names to come through reguardless of duplicate names, if I’m not mistaken this worked previously.

Any help or guidance would be appreciated
best
-Trevor

Hey @tfedyna ,

It looks like you are erasing the display_name at some point in your script. I don’t have any issues getting room identifiers that are different from the display names:

check_display_name_and_id.gh (31.8 KB)

Display names are always allowed to be duplicated and the model is still considered valid. Duplicate identifiers are considered invalid but we aren’t going to stop you from making them with the LBT SDK. We’re just going to give you a validation error if you run the validation command.

Thanks @chriswmackey! I appreciate it, Ill dive into my script and see all what is going on.
-trevor

@chriswmackey
Still unable to get Rhino side display names into grasshopper.
Here’s the script I’m using though its feeling like rhino–>grasshopper is where the issue is as when I disable my script and rephresh get model in the model component, the issue persists


Looking at the list, there are no duplicates, there are 3 display names that came through,
Attic (unique name) basement (unique name) and then one of many living_u’s come through and then the rest are identifiers like its not wanting there to be duplicate living_u display names.

if _model:
    
    _model.duplicate()

    rooms = [room for room in _model.rooms]
    
    counts = {}
    for i, room in enumerate(rooms):
        if room.display_name in counts:
            counts[room.display_name] += 1
            rooms[i].display_name = "{}{}".format(room.display_name +'-', counts[room.display_name])
        else:
            counts[room.display_name] = 1
            room.display_name = "{}{}".format(room.display_name +'-', counts[room.display_name])
    
    for room in _model.rooms:
        room.display_name = room.display_name + "{}".format('_L-'+room.story)
    
    for room in _model.rooms:
        print(room.display_name)
    

model_ = _model

Hey @tfedyna ,

This line of your code doesn’t make any sense:

You are making a duplicated instance of the model only to throw it away. You probably meant to do something like this:

model = _model.duplicate()

… then the rest of your script would edit the new model instance rather than the input _model. Doing this with your script, I thing things are working correctly where the identifiers are not affected:


check_display_name_and_id_for_trevor.gh (32.7 KB)

1 Like

Hi @chriswmackey I made the edits to the main component like you said, that makes a lot of sense about the model duplication, though I’m still having the same issue with the display names in my model not coming through.
I made a smaller file without a bunch of the other things im working on and attached it below with the model that has all the duplicate names
trevor_mf_room_name_issues.gh (34.2 KB)
multi_fam_validated3dm.3dm (1.4 MB)
I appreciate your help!
-trevor

Ah, I see what you mean.

You’re just talking about the discrepancy between the display_names of the Rooms in the Pollination Rhino Model tree diagram and the actual display_name that is assigned to the Room objects. You don’t need Grasshopper or Python to illustrate this. You just need to open up the Room properties and you can see that this is some type of bug in the Rhino plugin.

The room is supposed to have the name “living_u” under the panel but the Name is completely blank under the “Room Properties” dialog. Do you know how these rooms were named in the first place? If we can recreate the bug, then we can surely fix it or prevent it from happening again.

In the meantime, @mingbo , do you think you could take a look at the .3dm file @tfedyna uploaded and see what might be going to to make a discrepancy between the name of the rooms in the panel and those that show up under Room properties?

FYI, @tfedyna , I found the quick way to work around this is just to assign the Room names through the “Room Properties” dialog. If I do this, then all of the names are coming through as you would expect:

multi_fam_validated3dm_FIXED.3dm (1.8 MB)

1 Like

Hi @chriswmackey and @tfedyna,

The Room Manager will display the room’s identifier if its display name is not set or empty.

What you see “living_u” in Room Manager is the first 8 characters of the room’s identifier. I am doing this for not overwhelming Rhino users who are not used to seeing super long GUID-like identifier that usually used in Rhino plugin. This is a different approach to what Grasshopper plugin.

Hi @chriswmackey The original naming of the rooms was from importing a PNNL model after upgrading the version, the only room I named manually was the basement as it came in wonky and unacceptable for a HB room and I had to redo it.
-trevor

Thankyou for the workaround!

Thanks @mingbo ,

I understand the intention here is to not overwhelm users but this current implementation is really confusing as neither Trevor nor I could tell what was going on at first.

Most of the models where the Room display_name is unset are not using long GUID for the identifier. They are typically IDF names coming from an import like the one you see here:

living_unit2_BackRow_TopFloor

So I would really prefer to see the full ID in this case as it’s meant to be human-readable.

What is the case that you are worried about users seeing a long GUID? Is there any way that we can just isolate those cases and, instead of this setup where we can’t tell what the real name is, maybe you can just set the Rooms’ display_name to the truncated version of the ID?

This one was bugging me a little and I know that @mingbo is busy right now. So I just made a change to our “Open IDF” and “Open OSM” routine, which will ensure that the display_name always gets set to the IDF name of the object upon import from these files:

That should ensure that the confusion that happened in this particular case never happens again.

Granted, I still want to know what the cases are where @mingbo is worried about people seeing a long GUID and so he feels the need to hide the real identifier from us in the interface. Once I understand this, I might be able to get behind it.

Actually, maybe all that it takes is for us to add a “…” to the end of the truncated ID. Then, I probably would have understood that I’m only seeing part of the whole ID and I might not have been so confused here.

1 Like

Hi @chriswmackey,

In Rhino plugin, we use GUID for identifiers a lot of places, even though I improved with minimizing the length of GUID (like when adding a new room, it only takes a first eight digits of a GUID, and add “Room_” before it: such as “Room_xxxxxxx”). But still, it is too long and not readable from the UI.

I made some improvements as you suggested.
In the case of missing “DisplayName” of a room object, the UI will take the first 8 characters and add a “…” to the end.
Hope this clears up some confusion.

1 Like