@theoryshaw said:
I think i know what it's related to... after I created the aggregate, I moved the origin of the aggregate empty.
It takes into account the location and rotation of the original objects in relation to the original empty. Then it reproduces the same relationship based on the duplicate empty position and rotation. Here's what happens when you change it:
Hi @bruno_perdigao Just saw this, sorry.
I'm keeping the aggregate empty at (0,0,0), and it seems to work.
...
As you saw, there's this problem.
...
Also, as a feature request, would it be possible to increment the duplicates?
So instead of...
IfcElementAssembly/Assembly (original)
IfcElementAssembly/Assembly.001 (duplicate)
IfcElementAssembly/Assembly.002 (duplicate)
It changes the name to something like...
IfcElementAssembly/Assembly (original)
IfcElementAssembly/Assembly_1 (duplicate)
IfcElementAssembly/Assembly_2 (duplicate)
Reason being, when they are named with .001 etc, upon a reopening of the IFC, these aggregates get renamed. That is IfcElementAssembly/Assembly.001 could be renamed to IfcElementAssembly/Assembly, for example.
This makes in confusing, when adding stuff to the original (or parent) aggregate--as the name essentially always changes, when the IFC is opened again.
It takes into account the location and rotation of the original objects in relation to the original empty. Then it reproduces the same relationship based on the duplicate empty position and rotation. Here's what happens when you change it:
I think I've met similar problem - when you move the entire assembly (relation between original objects and empty doesn't change), "refresh assembly" still moves the objects.
Demo - https://imgur.com/a/5g345O2
Example to reproduce the issue attached (just run "Aggregate Refresh" on the second assembly")
Update! Just noticed the pull request and it solves the issue for me. Can we merge it or there is still something to add? @bruno_perdigao
@Andrej730 I changed my mind, since this PR is simple and already solved your issue, I think you can merge it. The other issues are related to another part of the code.
The refresh seems to be working as intended, but the instances are not organized the way as you expected (see below). I suspect the problem happened when you were duplicating them. Do you recall the order in which you created them?
@bruno_perdigao said:
The refresh seems to be working as intended, but the instances are not organized the way as you expected (see below). I suspect the problem happened when you were duplicating them. Do you recall the order in which you created them?
Hmm, it's now not refreshing aggregate if it's just IfcElementAssembly selected. Was it intended? Intuitively it seems that it should still work. And for the cases if you have assembly of assemblies you won't be able to refresh the main assembly by other ways besides selecting the main IfcElementAssembly empty.
Noticed another idea similar to that PR - when you add object to an assembly with eyedropper, perhaps it should be possible to select assembly child object and it would deduce actual IfcElementAssembly from that child. And not sure if there is any need for the eyedropper, similarly to Ryan's report about product assignment.
when you add object to an assembly with eyedropper, perhaps it should be possible to select assembly child object and it would deduce actual IfcElementAssembly from that child. And not sure if there is any need for the eyedropper, similarly to Ryan's report about product assignment.
@theoryshaw said:
Sorry for the onslaught of feature requests. Just using the 'duplicate aggregate' a lot lately so just want to write them down somewhere. :)
Keep it coming! I'll try my best to keep up.
The following scenario doesn't seem to refresh.
Am I missing something, or is this just not possible currently.
What I meant earlier is that the organization of parents and children is different from what you showed (or maybe I didn't understand correctly). What mean is shown in the image below. The refresh won't work if the assembly selected is a parent. So, in this case, it would work, for example, if you change parent B and refresh the child B. Maybe you are trying to refresh parent B because you expected it to be a child of A, is that right? If so, maybe the problem happened when you were duplicating them. Makes sense?
To get this, I checked the ID in the pset BBIM_Aggregate_Data. There has to be a better way to know which is the parent is which is the child, it's on my todo list to build this functionality
I saw this UI for "representation utilities" with this warning for advanced users, and I thought maybe we could have a subpanel under aggregates, called "duplicate aggregates", with the same warning. It would allow me to start testing a UI for it. Maybe it's too soon for this, since it is highly experimental, I don't know. What you guys think?
When you Shift+Ctrl+D an aggregate it will attach a BBIM_Aggregate_Data Pset to the objects inside both the parent aggregate and child aggregate.
If, however, you add an object to the parent aggregate after its initial creation, this new object does not have a BBIM_Aggregate_Data Pset. I assume that it should, correct?
I'm not sure how it happened, but if I refresh the following child, from this file, it makes the child disappear, and oddly highlights a few random objects in the parent, as you can see from the screenshot below.
This makes in confusing, when adding stuff to the original (or parent) aggregate--as the name essentially always changes, when the IFC is opened again.
...or does it make sense, on import(open) to assure that the parent is always named IfcElementAssembly/Assembly and the children are IfcElementAssembly/Assembly.001, IfcElementAssembly/Assembly.002, etc.
Would it be relatively easy to process multiple children at a time?
Reason being, processing each house module for this pocket neighborhood takes a lot of time, for just one refresh. If I could select multiple children modules and run the refresh on them, I could have it run over lunch, for example, and the entire model would be updated.
Might have spoke too soon. (might be a different problem though)
I recreated the following parent from scratch (after your fix), and then created the following child and rotated it 90 degrees.
If I refresh the child, it disappears.
file, here.
@theoryshaw said:
Would it be relatively easy to process multiple children at a time?
Reason being, processing each house module for this pocket neighborhood takes a lot of time, for just one refresh. If I could select multiple children modules and run the refresh on them, I could have it run over lunch, for example, and the entire model would be updated.
The reason I only allowed to refresh each child at a time was to prevent the user to start a very time-consuming process without knowing, but since you are aware of this, I can change the code to allow this behavior.
I recreated the following parent from scratch (after your fix), and then created the following child and rotated it 90 degrees.
If I refresh the child, it disappears.
I'll take a look
@theoryshaw For now, try using this script. Make sure to select only one object from each aggregate:
objs = bpy.context.selected_objects
for obj in objs:
for s in bpy.context.selected_objects:
s.select_set(False)
obj.select_set(True)
bpy.ops.bim.refresh_aggregate()
Comments
I think i know what it's related to... after I created the aggregate, I moved the origin of the aggregate empty.
Should the movement of the aggregates' origin be accommodated? or should it always remain at 0,0,0?
Is it the same file you shared before? Did I do anything different here?
It takes into account the location and rotation of the original objects in relation to the original empty. Then it reproduces the same relationship based on the duplicate empty position and rotation. Here's what happens when you change it:
@theoryshaw Any updates on this? The PR didn't solve your problem after all?
Hi @bruno_perdigao Just saw this, sorry.
I'm keeping the aggregate empty at (0,0,0), and it seems to work.
...
As you saw, there's this problem.
...
Also, as a feature request, would it be possible to increment the duplicates?
So instead of...
It changes the name to something like...
Reason being, when they are named with
.001etc, upon a reopening of the IFC, these aggregates get renamed. That isIfcElementAssembly/Assembly.001could be renamed toIfcElementAssembly/Assembly, for example.This makes in confusing, when adding stuff to the original (or parent) aggregate--as the name essentially always changes, when the IFC is opened again.
Hope that makes sense.
I think I've met similar problem - when you move the entire assembly (relation between original objects and empty doesn't change), "refresh assembly" still moves the objects.
Demo - https://imgur.com/a/5g345O2
Example to reproduce the issue attached (just run "Aggregate Refresh" on the second assembly")
Update! Just noticed the pull request and it solves the issue for me. Can we merge it or there is still something to add? @bruno_perdigao
@Andrej730 Let me take a look at these new issues to see if they are related. Then I'll try to add everything into a single PR
@Andrej730 I changed my mind, since this PR is simple and already solved your issue, I think you can merge it. The other issues are related to another part of the code.
The following scenario doesn't seem to refresh.
Am I missing something, or is this just not possible currently.
file attached.
The refresh seems to be working as intended, but the instances are not organized the way as you expected (see below). I suspect the problem happened when you were duplicating them. Do you recall the order in which you created them?
I meant to do the following as a pull request
https://github.com/IfcOpenShell/IfcOpenShell/commit/9e67565c71bbe3d0ea45302674345f47572ed874
It's easier just selecting a part, verses trying to track down the aggregate empty, to refresh.
hmm, not sure i quite follow you. See following video
https://www.dropbox.com/scl/fi/6s3ozscfla6tdvki9mdti/2023-09-20_09-06-11_community.osarch.org_discussion1454blenderbim-arra_chrome.mp4?rlkey=t7qgstzdztackuzs7yj8puny2&dl=0
I'm not sure where you got
DandEfrom.Sorry for the onslaught of feature requests. Just using the 'duplicate aggregate' a lot lately so just want to write them down somewhere. :)
...
Possible to have 'duplicate aggregate' work with arrays?
video: https://www.dropbox.com/scl/fi/ld6xql3qvhtxguzq5a7gh/2023-09-20_21-54-50_KeyShowView_Carnac.mp4?rlkey=xigy8mwindca39oh0j70t9tu1&dl=0
Hmm, it's now not refreshing aggregate if it's just IfcElementAssembly selected. Was it intended? Intuitively it seems that it should still work. And for the cases if you have assembly of assemblies you won't be able to refresh the main assembly by other ways besides selecting the main IfcElementAssembly empty.
Noticed another idea similar to that PR - when you add object to an assembly with eyedropper, perhaps it should be possible to select assembly child object and it would deduce actual IfcElementAssembly from that child. And not sure if there is any need for the eyedropper, similarly to Ryan's report about product assignment.
Nope!...just lack of programming skills. :)
https://github.com/IfcOpenShell/IfcOpenShell/commit/6536f7b56b72879a5d3c4ea26d416014c7713e62
Love the idea.
Keep it coming! I'll try my best to keep up.
What I meant earlier is that the organization of parents and children is different from what you showed (or maybe I didn't understand correctly). What mean is shown in the image below. The refresh won't work if the assembly selected is a parent. So, in this case, it would work, for example, if you change parent B and refresh the child B. Maybe you are trying to refresh parent B because you expected it to be a child of A, is that right? If so, maybe the problem happened when you were duplicating them. Makes sense?
To get this, I checked the ID in the pset BBIM_Aggregate_Data. There has to be a better way to know which is the parent is which is the child, it's on my todo list to build this functionality
I saw this UI for "representation utilities" with this warning for advanced users, and I thought maybe we could have a subpanel under aggregates, called "duplicate aggregates", with the same warning. It would allow me to start testing a UI for it. Maybe it's too soon for this, since it is highly experimental, I don't know. What you guys think?
I've attached another file, to hopefully better explain.
I like it! :)
All open source development is experimental. ;)
When you Shift+Ctrl+D an aggregate it will attach a
BBIM_Aggregate_DataPset to the objects inside both the parent aggregate and child aggregate.If, however, you add an object to the parent aggregate after its initial creation, this new object does not have a
BBIM_Aggregate_DataPset. I assume that it should, correct?video:https://www.dropbox.com/scl/fi/vo6jmb57u4g7z2aa53bjo/2023-09-22_21-47-53_Blender_blender.mp4?rlkey=0y46q3kbswqc2ghbzq58gszm7&dl=0
I'm not sure how it happened, but if I refresh the following child, from this file, it makes the child disappear, and oddly highlights a few random objects in the parent, as you can see from the screenshot below.
... could it be because some of the objects don't have
BBIM_Aggregate_DataPset, as mentioned above?...or does it make sense, on import(open) to assure that the parent is always named
IfcElementAssembly/Assemblyand the children areIfcElementAssembly/Assembly.001,IfcElementAssembly/Assembly.002, etc.@theoryshaw Could you test this before I submit to pull request? It should fix this problem. Hopefully, all the other problems were caused by this
Seems to work for me!
Would it be relatively easy to process multiple children at a time?
Reason being, processing each house module for this pocket neighborhood takes a lot of time, for just one refresh. If I could select multiple children modules and run the refresh on them, I could have it run over lunch, for example, and the entire model would be updated.
Might have spoke too soon. (might be a different problem though)
I recreated the following parent from scratch (after your fix), and then created the following child and rotated it 90 degrees.
If I refresh the child, it disappears.
file, here.
The reason I only allowed to refresh each child at a time was to prevent the user to start a very time-consuming process without knowing, but since you are aware of this, I can change the code to allow this behavior.
If I refresh the child, it disappears.
I'll take a look
@theoryshaw For now, try using this script. Make sure to select only one object from each aggregate: