Hi there,
We need to prepare IFC file with multiple Curtain Walls (none of them are the same). The IFC file has to contain all information about each Curtain Wall / Mullion / Panel. As a result it should be possible to view select any Curtain Wall Mullion/Panel and see both hosted Curtain Wall parameters (such as height, base offset, length etc.) and Curtain Wall Mullion/Panel parameters (glass colour, panel dimensions, profile type, profile dimensions). While the second part can be arranged, the first part (information about the actual Curtain Wall) seems to be complicated.
The list of parameters that has to be included in the IFC file contains:
— Curtain Wall Mark;
— Overall Curtain Wall weight;
— Overall Curtain Wall dimensions;
— Curtain Wall base offset;
— Glazing colour (this is easy, can be specified in Curtain Wall Panels);
— Mullion profile (also simple);
— Glazing dimensions (also simple).
Additionally:
— to include total glazing area of that Curtain Wall, and area of the wall itself.
Is it even possible? If yes, could you please help us?
Many thanks,
Mihails
Preview of the IFC file in the attachment.
Hi there,
We need to prepare IFC file with multiple Curtain Walls (none of them are the same). The IFC file has to contain all information about each Curtain Wall / Mullion / Panel. As a result it should be possible to view select any Curtain Wall Mullion/Panel and see both hosted Curtain Wall parameters (such as height, base offset, length etc.) and Curtain Wall Mullion/Panel parameters (glass colour, panel dimensions, profile type, profile dimensions). While the second part can be arranged, the first part (information about the actual Curtain Wall) seems to be complicated.
The list of parameters that has to be included in the IFC file contains:
— Curtain Wall Mark;
— Overall Curtain Wall weight;
— Overall Curtain Wall dimensions;
— Curtain Wall base offset;
— Glazing colour (this is easy, can be specified in Curtain Wall Panels);
— Mullion profile (also simple);
— Glazing dimensions (also simple).
Additionally:
— to include total glazing area of that Curtain Wall, and area of the wall itself.
Is it even possible? If yes, could you please help us?
Many thanks,
Mihails
Preview of the IFC file in the attachment.
Did you find out about this? I have a similar case where I want each panel to be separate in the IFC file.
Did you find out about this? I have a similar case where I want each panel to be separate in the IFC file.
Any answers? This is quite important.
When exporting 'standard' Curtain Walls to IFC the panels are 'hidden' deep within the IFC hierarchy.
A Curtain Wall that is face-based exports the Curtain Panels as individual objects.
Why is there this glaring discrepancy, dare I say A BUG in Revit's handling of an Industry Standard file format (IFC)?
And when will Autodesk ANSWER THIS QUESTION?
Any answers? This is quite important.
When exporting 'standard' Curtain Walls to IFC the panels are 'hidden' deep within the IFC hierarchy.
A Curtain Wall that is face-based exports the Curtain Panels as individual objects.
Why is there this glaring discrepancy, dare I say A BUG in Revit's handling of an Industry Standard file format (IFC)?
And when will Autodesk ANSWER THIS QUESTION?
Hi Mihails,
I realize this is a very old post, and maybe you've moved on from the "issue" or have found a workaround.
I'm not an Autodesk "fanboy" but I am not sure this is a valid complaint. It appears you are using some sort of forge-viewer to view the ifc-information, and the limitation for how the ifc-panels are nested to their containers is limitied.
I tried exporting a curtain-wall with panels to ifc and opened it in solibri. There I could select the individual elements, and see which elements were associated with the wall. Extrapolating information backwards doesn't seem to be possible, at least not with the simple export i tested.
In terms of carrying marks between panels and the walls they are hosted to; the workaround would probably be dynamo. I am a dynamo "fanboy" but also know how irritating it becomes when more than three or four scripts need to be run in order to achive a goal which should probably be more intelligently built-into the core software. This is not an ideal solution, and i haven't looked into it, but i can't imagine that there is a technical limitation to carrying information from the host-facade-wall into the individual components via dynamo.
I can't speak for autodesk, but I can imagine there are two factors at play here:
1. Creating references between objects in the Model uses resources. It might not be a lot, but every bit adds-onto how much computing needs to be done in order to keep information between elements linked. I have similar issues if I want to create parts for layered walls. If I update information in the host family, the information is initially carried over, but needs to be maintained separately afterwards. (Sorry, you can't divide a curtain wall....)
2. Autodesk probably is adopting a strategy of focusing on the core-product while allowing users to leverage the API with add-ins like dynamo and pyrevit. For smaller companies, this might be troublesome of you don't have the resources or luck to find someone who also has one of these skills. If you are a mid-sized or larger firm, you probably are just creating your own tools and solutions to deal with these issues. I can only recommend you learn some dynamo...it's a life-saver for me....
I am not an autodesk rep...just a guy who has been using autodesk products for close to two decades. Actually was searching for a solution to my problem...
Cheers
Matt
Hi Mihails,
I realize this is a very old post, and maybe you've moved on from the "issue" or have found a workaround.
I'm not an Autodesk "fanboy" but I am not sure this is a valid complaint. It appears you are using some sort of forge-viewer to view the ifc-information, and the limitation for how the ifc-panels are nested to their containers is limitied.
I tried exporting a curtain-wall with panels to ifc and opened it in solibri. There I could select the individual elements, and see which elements were associated with the wall. Extrapolating information backwards doesn't seem to be possible, at least not with the simple export i tested.
In terms of carrying marks between panels and the walls they are hosted to; the workaround would probably be dynamo. I am a dynamo "fanboy" but also know how irritating it becomes when more than three or four scripts need to be run in order to achive a goal which should probably be more intelligently built-into the core software. This is not an ideal solution, and i haven't looked into it, but i can't imagine that there is a technical limitation to carrying information from the host-facade-wall into the individual components via dynamo.
I can't speak for autodesk, but I can imagine there are two factors at play here:
1. Creating references between objects in the Model uses resources. It might not be a lot, but every bit adds-onto how much computing needs to be done in order to keep information between elements linked. I have similar issues if I want to create parts for layered walls. If I update information in the host family, the information is initially carried over, but needs to be maintained separately afterwards. (Sorry, you can't divide a curtain wall....)
2. Autodesk probably is adopting a strategy of focusing on the core-product while allowing users to leverage the API with add-ins like dynamo and pyrevit. For smaller companies, this might be troublesome of you don't have the resources or luck to find someone who also has one of these skills. If you are a mid-sized or larger firm, you probably are just creating your own tools and solutions to deal with these issues. I can only recommend you learn some dynamo...it's a life-saver for me....
I am not an autodesk rep...just a guy who has been using autodesk products for close to two decades. Actually was searching for a solution to my problem...
Cheers
Matt
Not sure why face-baced exports differently than non-face based.
Maybe there is an ifc-enumeration which allows this type of behavior?
Not sure why face-baced exports differently than non-face based.
Maybe there is an ifc-enumeration which allows this type of behavior?
IFC 2x3 or IFC4?
If IFC4, try exporting 2x3 and see if you get the sameresults.
Otherwise, check your IFC-Export settings at the global level, especially for sub-categories.
Then check IFC-Export settings at the type and instance level.
IFC 2x3 or IFC4?
If IFC4, try exporting 2x3 and see if you get the sameresults.
Otherwise, check your IFC-Export settings at the global level, especially for sub-categories.
Then check IFC-Export settings at the type and instance level.
Can't find what you're looking for? Ask the community or share your knowledge.