I decided to use VisualARQ 3 to import IFC.
However, I have a problem with the Object Parameters created during IFC import. Because the parameter names are repeated, they have numbers added to them, e.g. (001). I don’t know which of the repeated parameter names will have a number added to them and which will not. The solution to the problem would be to first refer to the parameter category, and only then search by name.
However… it is not possible to select objects and extract parameters from them that I can deconstruct, it seems to me that this deconstruct operation is only possible for the VA Document Parameters. Is my observation correct? This is a serious problem.
I wanted to use VisualARQ to import IFC and use the values of the object parameters in the Grasshopper for various types of filters and views (just like in the IFC browser, e.g. Bim Collab). Grasshopper would serve me very well here.
Doubled parameter names, but inside other categories and with different values
Referring to the IFC parameters is very confusing.
In the Rhino Properties:Parameters panel, the parameters are written in uppercase letters. Notice that we have two different types, the Rhino object type (block instance) in “General” and the Type in the “Other” category - the name of the type from Revit.
However, the Property Names component returns names that are written in lowercase, it looks like “internal names” and some other parameters are devoid of special characters, e.g. instead of “Angle (001)” we have “angle001”.
This makes referring to parameters by name alone almost impossible. In another thread I raised the problem of not being able to break down Object Parameters and get categories and descriptions.
Anyway… if I want to reference “General” Type I need to use lowercase “type” and to reference “Other” Type I need to reference “Type”.
Hi @Czaja Excuse the late reply on this topic. Right now VisualARQ doesn’t accept parameters with the same name. It is not possible to create one with a name that already exists (even if it is in a different category), and for that reason when it imports an IFC file with different parameters with the same name, it adds numbers to distinguish them.
We have plans to change that, and you will be able to have parameters with the same name, at least when they are in different categories.
The “Type” parameter is a built in property that all entities have (just like “Volume”, “Area”, “Name”…).
In that case, you can create a custom parameter called the same way (“Type”, “Area”, etc). This of course leads to confusion when it comes to reference one or another. We will study how to handle this problem (along with the other request of managing parameters with the same name, but in different categories)
However, because of the different object types that are created during the IFC import, it’s a bit messy right now in Grasshopper. I think it would be easier if all elements came as Block Instances for the sake of consistency.
For example, you can’t pass what came from the IFC import as Block Instances through the Geometry, and you can’t pass Breps, Meshes through the Block Instance component (obviously).
This means that at the very start, you need to branch out geometry to get the object parameters.
If I see it correctly, single geometry elements come as mesh or breps and multi-geometry IFC elements are imported as Blocks. From the user’s perspective, there is no benefit from that - quite contrary, it causes troubles.
It’s messy also in the later stage, but I think it’s not necessary to write about that.
Since there is some work being done with IFC import I’m bumping this issue. There is no benefit in having a mixed bag of Extrusions, Breps, Meshes and Block Instances, quite contrary, it’s something that I need to filter and group manually. It would be much better to have everything as Block Instances IMO.
@Czaja I see there is an issue between the Query Model Object and the Property Names components. We will review this.
You can use the VisualARQ and Geometry Pipeline components to read block instances, breps, meshes and VisualARQ objects instead. Does that work for you?
