Hi,
I am very impressed with the ability to import/export the IFC file from Rhino with VisualARQ.
Our tasks are to modify IFC models to work correctly with our applications and we thought that VisualARQ is an amazing solution. However, we could not find any option to include Base Quantities for the IFC exporter. Is there any option to export Base Quantities for the entities?
Thank you in advance.
Hi @JunghwoPark,
The following data is included by default in the Ifc file:
This is what gets exported for some of the elements for example:
If you are asking for a different thing, or you need something that is missing here, let us know.
Kind regards
Dear Ramon Carceles,
Thanks a lot for your kind instruction.
For us, it is very important to get BuildingSMART’s Standard BaseQuantities as a PropertySets.
For example, we need Base Quantities for the IfcWall as follows:
GrossFootprintArea
Height
Length
NetSideArea
NetVolume
Width
One of the examples of Wall Base Quantities from Revit and view in Solibri
Please see the attached images.
VisualARQ does export IfcElementQuantity but we wish to get Pset name as Base Quantities including some of the missing information, such as GrossFootprintArea, Width.
We would like to have all IfcEntities including IfcSpace with BaseQuantities from VisualARQ.
Would it be possible to get it?
Apart from that our test with VisualARQ is very optimistic as Rhino can import many CAD file formats so that we can modify and export back with IFC2x3 CV2.0 format by using VisualARQ. However, missing BaseQuantities make us hard to use cost estimation softwares in order to leverage the data from IFC.
We are looking forward to hearing from you. Thank you for your support.
Best regards
Junghwo,
Hi @JunghwoPark,
Thanks for all the information.
We chose IfcElementQuantity because it is meant to describe physical properties of elements.
Of course is not the only way, that’s why Revit is exporting it in a different way.
But is there a reason why you need it as a PropertySet named BaseQuantities?
We are going to add those two (GrossFootprintArea and Width) to the IfcElementQuaniry so you can find all the data, let us know any other that you may need.
Kind regards
Hi Ramon Carceles,
Thanks for the answer.
You are right. IfcElementQuantity is the right way to categorize according to BuildingSMART.
However, our team needs Pset called BaseQuantities to filter gross and net values from our application.
Base quantities are quantity definitions that are independent of a particular method of measurement and therefore internationally applicable. Base quantities are defined as gross and net values and provided by measurement of the correct geometric shape representation of the element. This specification includes a set of base quantity definition. See each subtype of IfcElement for applicable base quantities.
The following general agreements apply for each base quantity set
I do not think VisualARQ will completely change the Pset Name from IfcElementQuantitiy to BaseQauntities. However, it will be nice to have the option to add or modify Pset Names in the future.
In fact, GrossVolume, GrossSideArea, GrossFootprintArea, NetSideArea, NetVolume, NorminalHeight, NorminalLength, NorminalWidth would be nice to have for IfcWall…
I know, we could calculate quantities with Grasshopper and add them as additional information. But it needs some efforts to do it and it would be nice to include at least Length Quantity, Area Quantity, and Volume Quantity of both Net and Gross values in the Pset would be super nice. Additionally, if we can customize the name of Pset will be even nicer.
Thank you.
Hi @JunghwoPark ,
The Pset name can be customized if they are created as groups of custom parameters. If you name them BaseQuantities they will appear as VaIfc_BaseQuantities like in the images below.
We could think about changing or removing this prefix if it is still a huge problem.
To automate assigning the values to those parameters you could create them by style and then use a Grasshopper definition with the Update Property component to set the value.
What we can do in the future to avoid using Grasshopper is to have a set of predefined parameter values that correspond to the physical properties of the building elements (Length, Area, Width, etc). That way you would be able to link them easily.
In the current IfcElementQuantity we can add all the net and gross values that are part of the Ifc2x3 specification.
Kind regards
Hi @RamonC,
This is great support. I do not really think we need any Prefix before BaseQuantities so that we can unify the Pset name to the international standards.
This workaround with GH component is great. Would it be also work for the native Rhino Geometries instead of VisualARQ Type elements?
I meant, we will most likely import many different CAD format in order to assign IfcEntities and Parameters. In this case, we will not generate VisualARQ styles… We preper to reference the layers from original CAD model and assign them to IfcEntities by using GH.
Thanks heaps and I see there is huge potential with VisualARQ.
What an amazing software!
best regards
Junghwo,
Hi @JunghwoPark,
I will let you know what we decide about the prefix of the Property Sets.
Yes, you can use custom parameters on any object. And you can create them either by document, by style or by object. Check out this video if you want to know more: https://www.youtube.com/watch?v=rdX7I79qTTI.
When you use the Update component to set the value of the parameters just make sure the parameter already exists on the object. That’s why it is recommended to use the Property Names component, which will give you a list of all the fields available on an object.
About the Ifc entities, when the object is not a VisualARQ you can use the same component (Update Property) to set a custom Ifc type. Example: UpdateObjectParameters.gh (12.3 KB)
Note that for Rhino geometry, the Ifc type, description and tag are actually added by VisualARQ as Attribute User Text. That’s why if you are working with some GH plugin that lets you add user texts to all the geometry in a layer (like Elefront) you can use it as well.
The limitation I see if your are not using VisualARQ objects is how to get the quantity values, for example the side areas of walls.
Hi @RamonC,
Thanks a lot for the reply and support.
It is great help. I thought that you can assign IfcTag for Rhino Brep as IfcWall Entity… Then VisualARQ automatically can export BaseQuantities… am I wrong? I must try to test…
Thank you.
Hi @JunghwoPark,
You can tag Rhino geometry, like a brep, with any of the provided Ifc tags, however this won’t create the quantities for that geometry because VisualARQ can only calculate quantities on native BIM objects.
Regular geometry can have any shape so it would be very difficult to calculate, just think about guessing the path of a geometry that you tagged as a wall.
When using Rhino geometry the resulting Ifc file contains the Ifc entities, like the IfcWall, with its associated representation, for example IfcShapeRepresentation > IfcExtrudedAreaSolid. This is still useful for calculating volumes, amounts of entities, etc.
Kind regards
Hi @RamonC,
I understand. At least we can calculate quantities based on IfcShapeRepresentation and perhaps, I should create GH script to automize non-native BIM objects to feed BaseQuantities as a custom property set. This might help our QTO team to get useful information. Thank you for all the comments and supports.
Best regards
Junghwo,
Hi @JunghwoPark,
It’s actually not true what I said about being able to calculate data of tagged objects if you expect to do this calculations inside VisualARQ. For that to work VisualARQ styles should be used instead of just tagged geometry, otherwise even if you tag a box with an IfcFurnishingElement it won’t appear in the list of furniture.
This means that the easiest solution would be to create styles with a block representation. Unfortunately it is not possible to do that for all the styles yet.
With styles by block at least you will be able to count them and get the volume, however if you need more data you will have to use some kind of script to calculate the values from the geometry as you said.
Regarding the BaseQuantities for native VisualARQ objects, it’s going to be easier than we thought and probably for 2.9 version a BaseQuantities property set will be available.
Kind regards
Hi @RamonC,
Thanks for the additional information.
I am glad that BaseQuantities might be updated for the next version.
I hope VisualARQ updates all supported IFC Entities not only the wall of BaseQuantities.
Thanks again for your support and I think we have already request a license to our IT department to work with it.
Best regards
Junghwo Park,
Hi @JunghwoPark,
The 2.9 version has been released and from this version “IfcElementQuantity” has been renamed to “BaseQuantities”.
Kind regards
Hi RamonC.
I found the discussion interesting and just wanted to add my 2 cents on the topic. I believe that the issue has now been solved because of the name change in VisualArq to Basequantities. I just want to add some info why the Basequantities is an essential propertyset in case it might be unclear to others.
I have been assisting Architectural Competitions by analysing their Ifc Models. The Basequantities usually get predefined in Contracts or modelling guidelines for a project and if the architect or modellers don’t manage to have their native softwares measurements i.e. BaseQuantities in the ifc they usually get in trouble. The BaseQuantities is often read automatically by the software or scripts written by companies who analyse the ifc data. So no Basequantities always means that the external companies and people down the line lose more time getting information out of the models, which then compunds the problem and could lead to longer project times or higher costs.
exactly! and thanks for the comments!
This is the issue with the naming conventions from VisualARQ for example.
I will have to test new version 2.9 regarding BaseQuantities.
