Indeed \X\0D will be rewritten by IfcOpenShell to \X2\000D\X0\ but they are equivalent encodings
I've been reading this thread, and I have the same problem as the OP.
Can't manage to delete an IfcBeam instance from this file.
Tried unlinking, deleting and exporting under a different name.. this horizontal beam keeps appearing.
Deleting seems to work for me. I'm on Windows.
video:
Are you on Mac?
Maybe same problem @ChubbyQuark had here?
Picking up this Convo again, also have the same issue, I tried with all these test files people had problems with and have the same issue with every IFC,
running windows 10, latest Blenderbim and Blender 3.2.2 through Steam, it's definitely something to do with the system or setup and not the IFC files here.
Tried the process on another PC and delete works no problem on all the files
Anyone got any ideas?
Here also the same issue. Moving elements seems to work but deleted elements keep reappearing when importing the IFC.
For some odd reason when I rename the IFC file and move it to another folder, I can delete IFC elements. Will try to reproduce it somehow.
I have definitely seen this problem, but can't reproduce, it is likely related to geometry cacheing.
I don't see it on Linux, where cacheing doesn't work at all due to the way I install blenderbim on my system, but I do see it on Windows.
I resolved it on Windows by uninstalling blenderbim and reinstalling, which presumably clears the cache.
The latest unstable release from Github does not have caching enabled by default. Can anybody reproducing this bug test with that version?
Hey @Moult
I've made a short vid with the issue and the latest blenderbim:
Here are the two ifc files used aswell:
Looks like there's 2 bugs there, potentially unrelated. The other being those IfcBeams that magically show up. :)
I replicated this IfcBeam bug w/ 0.0.220822. Was not able to replicate the delete problem. Windows 10
@brunopostle uninstalling blenderbim and reinstalling did the trick. It works as expected now. (blender v3.1.2 and blenderbim v0.0.220516). Thnx!
Update: uninstalling blenderbim worked for a test file. Yesterday I tested on a project and initially it worked fine but later the same issue reappeared. I did a clean install of the latest versions of blender and blenderbim this morning and tried to find out at what point things go wrong:
Deleting only elements works.
Deleting spaces and saving the IFC (or saving as) results in Blender crashing.
Deleting elements in a blender file that has chrashed before will reappear.
Loading the IFC (after blender chrased) in a new blender file fails and gives an error.
@pstrokap can you upload your file or send to dion@thinkmoult.com if private with a step by step of how to reproduce the crash / error? These types of bugs are high priority to fix.
@bruno_perdigao said:
I'm not really sure, but I suspect it has to do with the tree organization. The emptys representing
IfcSpacialStrutuctureElementshould be inside their respective collection. For example, bothIfcSiteare inside the collection "IfcSite/My Site.002".
This raises a topic that is seriously messing with me. I see with the IFC import, a lot of empties, representing say a floor level, but none of the elements on the given floor a children of said empty. This is obviously more of a Blender internal structure issue than IFC issue per se. But I am wondering if the parent child relationships can/should be structured inside the Blender file?
Similarly, the IfcOpeningElements (in my current project at least) are in a completely separate (single openings) collection. Should they not at the very least, be grouped into their respective floor level collections? And of course following on from this, should there not be a relationship between the opening element and what sits in that opening eg a window has an opening element and the actual window element, and then too, to the hosting wall element?
Perhaps I am overthinking this, but it seems that the strength of the IFC thing is the relationships within the project?
Hi!
Sorry folks.
Been dealing with some personal family related issues...
Below is a youtube link showing my actions regarding deleting an IFC object.
Enjoy :)
System : MacBook Pro (M1, 2020) macOS Monterey
Blender version: Intel 3.3 /3.2 / 3.1 (fails on all )
BlenderBIM: Latest experimental build-220831
@pstrokap deleting all spaces (250 elements) is a bit expensive so the save process on my machine takes 250 seconds to complete, but it does complete successfully. Did Blender actually crash for you or did it just go unresponsive, and if unresponsive, have you tried waiting longer? For me, I am able to delete random objects and all spaces successfully.
I recently made a change for supposedly better / faster deletions, and today added support for an experimental feature to disable transactions on export (the first benchmark mentioned in the commit description is with your file).
If it still doesn't work, catch me online during the Sydney timezone on osarch.org/chat and let's screenshare.
@sceyefeye said:
I see with the IFC import, a lot of empties, representing say a floor level, but none of the elements on the given floor a children of said empty.
This is an optimisation issue. The relationships are there in the object properties (you can see the IFC Spatial Container panel in Object Properties Tab) so all the relationships are retained. However, merely they haven't had Blender parent-child relationships created. That's because it is largely unnecessary to do so. It's not guaranteed that the user wants or cares about the Blender parent child relationship, and having these relationships on a model with 30,000 objects is not scalable. If the user wants to move the floor as a whole, they can do that by right clicking the collection and clicking "Select Objects".
Similarly, the IfcOpeningElements (in my current project at least) are in a completely separate (single openings) collection. Should they not at the very least, be grouped into their respective floor level collections? And of course following on from this, should there not be a relationship between the opening element and what sits in that opening eg a window has an opening element and the actual window element, and then too, to the hosting wall element?
The opening elements are in their own collection because that currently reflects the IFC decomposition tree - openings are only indirectly included in the decomposition hierarchy. This also makes it easy to show/hide openings because openings are generally "invisible" objects. If they were in the storey, how would you easily toggle their visibility? I guess we can build a feature for toggling the visibility. Would that be better?
When editing with the BIM Tool you can toggle opening / hosted element relationships so they move with the parent and so on. This creates the Blender parent-child relationships on the fly. The hotkey is Alt-O.
@haukj I duplicated your steps exactly and it works for me. What doesn't make sense to me is that you are using an M1 which is the ARM architecture which we don't have daily builds for, so how did you manage to get build-220831? Did you compile it yourself? It would also be good to catch me online on osarch.org/chat and let's screenshare and if you don't mind we can do some debugging on your machine.
@Moult I use the intel version of blender...so...ahaa...maybe the emulator is an issue here?
Sorry. I was sure I mentioned this detail earlier in this discussion
MacBookM1-Emulator-Blender(Intel)-BlenderBim :D
@haukj ah OK, I have no idea. It would be nice for you to drop into https://osarch.org/chat and let's do a screenshare to debug together. I might ask you to edit a bit of code to see exactly what's happening. I'd also like to learn more about this emulator so I can add it to the installation instructions for M1 users.
@Moult said:
This is an optimisation issue. The relationships are there in the object properties (you can see the IFC Spatial Container panel in Object Properties Tab) so all the relationships are retained. However, merely they haven't had Blender parent-child relationships created. That's because it is largely unnecessary to do so. It's not guaranteed that the user wants or cares about the Blender parent child relationship, and having these relationships on a model with 30,000 objects is not scalable. If the user wants to move the floor as a whole, they can do that by right clicking the collection and clicking "Select Objects".
Okay, so it is for programmatical reasons? Really only bothering me from an "OCD" perspective.
I would just like to see the hierarchy in visual format as it makes it easier, for me, to understand the relationship of the project elements and how they relate to the whole.
The opening elements are in their own collection because that currently reflects the IFC decomposition tree - openings are only indirectly included in the decomposition hierarchy. This also makes it easy to show/hide openings because openings are generally "invisible" objects. If they were in the storey, how would you easily toggle their visibility? I guess we can build a feature for toggling the visibility. Would that be better?
It's more from the point of operation, that if I delete a window, its opening should similarly disappear. Of course this means that the openings would have to be implemented as Booleans, and following from that, that the hosting elements' geometry needs to be reconstructed without the opening, and then a Boolean operation applied. So yeah I get that it would take a level of "AI" or some other discretion to recreate the geometry. So I do get it that if the geometry has been poorly exported from one tool and then opened in another, there is only so much that can be done programmatically
When editing with the BIM Tool you can toggle opening / hosted element relationships so they move with the parent and so on. This creates the Blender parent-child relationships on the fly. The hotkey is Alt-O.
Ta
Yes, for optimisation reasons it's not practical to have 30,000 objects with relationships. The solution is to create the relationships on the fly as you edit portions of the model. Like in your example, BlenderBIM should automatically propagate to the opening. This is not impossible, just not coded yet. There's still a lot of work to be done on core stability and system architecture before I can focus purely on quality of life features for native authoring unfortunately.
T> @Moult said:
@haukj ah OK, I have no idea. It would be nice for you to drop into https://osarch.org/chat and let's do a screenshare to debug together. I might ask you to edit a bit of code to see exactly what's happening. I'd also like to learn more about this emulator so I can add it to the installation instructions for M1 users.
Sure! I'm located in Norway, and at work right now, so I cant join you right now..
@haukj we can try the weekend, or to be more organised feel free to send me a meeting request at dion@thinkmoult.com