@aothms said:
The issue is that most people want to insist on the IFC spatial hierarchy from project > site > containment | aggregation > openings > fills to remain a strict tree (so every child exactly one parent except the root). And openings in multiple elements violate that.
I have one doubt: why is this a problem but then geometric representation can be shared among various products using mapped representations?
Well there's various answers you could give to that. IFC distinguishes rooted and non-rooted or "resource" entities. The representation is a resource and it doesn't have an "identity" and therefore from IFC's point of view, it doesn't make much of a semantic difference whether it is shared or not. Another answer you could give is that conceptually a model is multiple juxtaposed trees (containment/decomposition, type+geometry to element, material to element, ...). Or, as other people would argue, both are a problem. If we wouldn't have shared resources within a model we probably would have solved sector wide incremental exchanges for a long time already.
@cvillagrasa one thing I'd like to add is that the concept diagram for mapped representation shows how it should correlate with types. Therefore strictly the only time you should share representations is when it shares a type.
Of course, some people don't follow this rule...
Thanks a lot to both! @Moult ok, so indeed the mapped geometry concept states that "elements may have a 'Mapped Geometry' representation that reuses the concept Product Type Shape".
I'm having one more doubt, though. @aothms I'm attempting to recreate your awesome IfcOpenHouse, from more than 10 years ago (btw, impressive to be building all of that in 2012!), and I'm not understanding something with the roof. In the cpp source, you say:
The geometry is instantiated by using IfcMappedItems. This way geometry definitions can
be reused while maintaining the cardinality constraint that the ShapeOfProduct relation
imposes on the IfcProductDefinitionShape. Note that this constrained is lifted in IFC4.
And the IfcRoof is created as an aggregate of two IfcSlabs, with both having a mapped representation pointing to the same IfcShapeRepresentation, without using types. And BlenderBIM correctly displays it. On the other hand, I tried not to use mapped items and just ifcopenshell.util.element.copy_deep the representation of one slab so as to achieve that strict tree hierarchy, but in that case BlenderBIM just shows empties for the slabs.
I know the original IfcOpenHouse was designed in IFC2x3, and I'm using 4x3, but is there anything obvious I'm missing with what I've said?
@cvillagrasa is it possible to share your script and/or the resultant IFC?
Well, IfcOpenHouse was a learning exercise for me as well. And there are definitely things that could have been done better. I wouldn't take too good a look at it. I think equating mapped items with types is also still fairly recent and somewhat speculative. If you take a look at this file for example https://raw.githubusercontent.com/IfcOpenShell/files/master/acad2010_objects.ifc (but yes 2010 and autocad which is not really bim anyway) you see the stair railings all being mapped items within a bigger representations where non-uniform scaling is used to scale the structs to the correct depth. I think the community kind of moved away from this as it is rather unsemantic, but as there has never been a formal validation in place for adherence to these kind of usage requirements you also don't really know.
@aothms it's been definitely very interesting to learn! I'll polish it a bit and publish a Jupyter Notebook, which I think can be also valuable to people learning the high level Python API today.
@Moult for now, here's a snippet of the roof creation, and the current IFC is attached:
roof = ios.root.create_entity(file, ifc_class='IfcRoof', name='Roof', predefined_type='GABLE_ROOF')
ios.spatial.assign_container(file, product=roof, relating_structure=storey)
roof_representation_south = ios.geometry.add_wall_representation(
file, context=body, length=roof_size.x, height=(storey_size.y / 2 + wall_thickness + roof_ledge.y),
thickness=roof_thickness, x_angle=(180 - roof_angle) * np.pi/180
)
roof_representation_north = ifcopenshell.util.element.copy_deep(file, roof_representation_south)
roof_downward_offset = (roof_ledge.y + wall_thickness / 2) * np.tan(roof_angle * np.pi / 180)
south_roof = ios.root.create_entity(file, ifc_class='IfcSlab', name='South roof', predefined_type='ROOF')
ios.geometry.assign_representation(file, product=south_roof, representation=roof_representation_south)
ios.geometry.edit_object_placement(
file, product=south_roof, matrix=placement_matrix(
[-roof_size.x / 2, -roof_ledge.y - wall_thickness / 2, storey_size.z - roof_downward_offset],
z_local=[0., 1., 0.]
)
)
north_roof = ios.root.create_entity(file, ifc_class='IfcSlab', name='North roof', predefined_type='ROOF')
ios.geometry.assign_representation(file, product=north_roof, representation=roof_representation_north)
ios.geometry.edit_object_placement(
file, product=north_roof, matrix=placement_matrix(
[
roof_size.x / 2,
storey_size.y + 3 / 2 * wall_thickness + roof_ledge.y - roof_size.y / 2,
storey_size.z - roof_downward_offset + roof_size.z + roof_thickness / roof_angle_cos
], x_local=[-1., 0., 0.], z_local=[0., 1., 0.]
)
)
ios.aggregate.assign_object(file, product=south_roof, relating_object=roof)
ios.aggregate.assign_object(file, product=north_roof, relating_object=roof)
The ios thing is just some artifact to avoid strings in ifcopenshell.api.run.
I'll polish it a bit and publish a Jupyter Notebook
Feel free to put it here: https://github.com/IfcOpenShell/academy/tree/main/posts
@cvillagrasa there are a number of validation issues with your model which you can run ifcopenshell.validate (or press the checkmark button in the debug panel in Blender). However the one related to your missing roof is that extruded area solids need to have a positive extrusion depth whereas you've given it a negative depth.
By the way you might want to check out ifcopenshell.util.shape_builder :)
@aothms thanks a lot! I'll try to advance with it next week. At the moment I'm organizing it with an external Python module to shorten a bit the notebook, and also with a JavaScript file which uses IFC.js for viz (and all the Node.js things, bundle, etc.), so with all of that I don't know if it's better to fork your IfcOpenHouse repo and just place a markdown with a link on the academy repo.
@Moult yeah, that's going to be caused by the weird angles in the snippet above. Tried to quickly change it and it seems to be improving... right?
??
I did indeed see shape_builder, it looks great! but it's a bit lower level and requires more commands. At a higher level, to me add_wall_representation, add_slab_representation and add_profile_representation look more or less like the same thing, which construct an IfcExtrudedAreaSolid. Would it make sense to have a combined add_extruded_representation which returned an IfcShapeRepresentation and took rectangular width, depth, or alternatively a full IfcProfileDef? also with some options for cardinal point insertion, like add_profile_representation at the moment?
By the way, one thing I wanted to achieve in the Jupyter environment is that when running a cell with say: entity = ios.root.create_entity(file, ifc_class='IfcWall'), and then regretting and re-running it with entity = ios.root.create_entity(file, ifc_class='IfcSlab'), the previous wall entity got handled from the file. I managed to achieve it with Python audit hooks and ifcopenshell.util.element.remove_deep2, but it's not reliable and it makes the kernel reload when removing certain representations (for instance, east/west walls in this model). It doesn't happen when overwriting other representations, like the roof ones. I've read a bunch of GH issues with some reported crashes and the creation of remove_deep2, and I get this can be complex, but it would be awesome to achieve that experimentation environment that Jupyter Notebooks provide, without having to rerun everything for any single change.
Where can I find the latest tutorial on how to update voids with the BlenderBIM add-on? I don't understand how to adjust the size.
This doesn't work :-(
@Coen said:
This doesn't work :-(
Spoke to soon, it works. just shoudn't rotate it in edit mode.
@Coen said:
@Coen said:
This doesn't work :-(
Spoke to soon, it works. just shoudn't rotate it in edit mode.
Spoke to soon again,
How to modify the length as I have drawn with red arrows? I am compleltely clueless:
This?
In edit mode you can only tweak the profile. Go back into object mode. I think this information may be available in the 3D viewport but you can go to the mesh properties, expand "Get Representation IFC Parameters" and tweak the value there.
This will display a gizmo in the viewport that you can click'n'drag but I don't think it can be trusted blindly :)
@Coen said:
@Coen said:
This doesn't work :-(
Spoke to soon, it works. just shoudn't rotate it in edit mode.
Spoke to soon again,
How to modify the length as I have drawn with red arrows? I am compleltely clueless:
@theoryshaw said:
This?
Yes thank you! What a well hidden sneaky button ?
@cvillagrasa said:
I'll polish it a bit and publish a Jupyter Notebook, which I think can be also valuable to people learning the high level Python API today.
As a last reference in this thread, here's the new thread about the recreation of the IfcOpenHouse:
Login or Register to reply.