Using Blender's collection instances, as a way to manage 'linked aggregates'?
T
by theoryshaw on 23 Dec 2024, edited 30 Dec 2024#
+2 votes
@bruno_perdigao do you think there's any merit to using Blender's collection instances, as a way to manage 'linked aggregates'?
Out of the gate, it would seem to improve the speed to 'refresh' the linked aggregates--as currently this is pretty painfully slow.
T
by theoryshaw on 23 Dec 2024, edited 23 Dec 2024#
+1 votes
I mean, how cool would mirroring be too? ;)
T
by theoryshaw on 23 Dec 2024, edited 23 Dec 2024#
I know mirroring opens another can of worms.. so you can disregard that, in light of this proposal.
...
It would seem like you'd only have to save the IfcProduct (ex: IfcWall) and its placement in the IFC file. All other stuff would be the same, it seems--that is, multiple IfcWalls, for example, could share the same representation, and psets, etc.
I agree. I was just thinking if a simpler implementation would already be useful, specifically using collection instances just to visualize and edit linked aggregates, while keeping the current system of removing and copying new elements solely for saving the file. However, sharing representations and psets is definitely an option worth exploring.
I don't think it would help. The fundamental issue is that the current express-based IFC has no kind of data-model level intelligence where data can be 'inherited' over instances. Everything needs to be either implemented in software (e.g property sets inheritance from type object to occurrence) or specifically instantiated and connected ad nauseam (IfcRelDefinesByObject). Doing that in C++ would only make things less flexible.