Brainstorming with BIM Featured
Everyone needs to organize models from their own viewpoint, but how is this best done? The most typical organizing structure is a hierarchical tree that contains all objects, but each object only once. The starting point for this are all the relevant objects in the model that are split into groups by a rule, typically by the value of a property. But when these groups are further split this does not happen using the same rule for all groups.
This is called ‘brainstorming’ because you don't necessarily know in advance what kind of steps and rules you need to get to the desired result, so you need to freely try different approaches until you find the best one.
Let's say the first split finds a broad class, like walls and doors. But after this walls are split by type and doors maybe by interior vs. exterior. Then the wall types are split by thickness and doors by type, like single swing, double swing, revolving etc.
Rule: Wall → Wall Type → Thickness
Rule: Door → Interior/Exterior → Type
This is in essence the brainstorming that Simplebim supports with object groups in general and the ability to create child groups with rules. In practice this can first be experimented manually using the Objects and Properties palettes and captured in a reusable dataflow once you figured out the correct way to create the hierarchy you need. Again, nothing too complicated - but very useful.
Comments
1 comment
This well describes how we arrive at a “useful” model structure: we don’t start with a forced hierarchy, but we brainstorm the “right” one by exploring what matters - for each object type and for the questions we want to ask from the model.
This turns grouping from a constrained task into a purpose‑driven logic! If we pause for a moment and look at our use cases through this “free grouping” possibility: most of them suddenly become simpler to solve, don't they?
I agree that trying it manually first, helps a lot to understand how it works: freely experiment, split, regroup… Then, once the final logic is clear, why don't preserve it as a Dataflow? It’s not over‑engineering, but just allowing automation to take over and make our final logic reusable, once that “brainstorming” is done.
Please sign in to leave a comment.