GC BIM Elements Update?

Hi All,

Just wondering about what is happening with GC BIM Elements.

I stumbled upon B-Processor; an open source project being developed by some Danish academics, with input from a number of Scandinavian building firms. The project was presented by Kristian Agger at CAADE '07. See the links to the powerpoint and short paper, and the really impressive tutorial vids. There is also a PhD blog by Sebastian Gmelin, who is using it for his dissertation.

IMHO, GC BIM Elements need to avoid being developed as just GC versions of BA’s walls etc, that are slaved to the GC ‘god script’ DAG way of working. Buildings are not designed using law curves and we don’t place doors using sliders. The option to work this way is great, but not sufficient on its own.

 

I think B-Processor’s origins as an architect-centric building modelling tool is responsible for the simple (but functional) way it handles / aggregates the relationships and 'reactions' between its intelligent scripted objects.

 

On the face of it, B-Processor offers a very clear and ‘natural’ (a bit of Knowledge Representation at work?) way to break up and control the ‘intelligence’ pent up in each building object, thereby negating the problematic requirement for a ‘master script’ or ‘master-scripter’.

 

B-Processor’s simple use of 'fields' to form ‘functional’ and ‘constructional’ spaces that have nested ‘Element’ and ‘Parts' is a flexible way to aggregate objects that also allows a ‘natural’ way to control LOD and component variation. It may not provide all the answers, but I think a good 'running-mate' to have?

 

The whole ‘building as aggregation of spaces, defined by skeleton geometry’ way of working also reminds me of the usefulness of having an available ‘topology’ in the GIS world. The way 'simple' geometric info like lines and shapes are looked at in terms of inside, outside, neighbouring etc (Implicit mathematical representation instead of parametric) and how this informs the way they are handled using rules-based processing is pretty amazing. Maybe a way to provide the ‘spatial indexing’ mentioned by Marques and Woodbury when they suggested that ‘explicit relationships’ were less desirable than ‘implicit’ ones.

 

 

 

  • Bentley Interoperability Platform:

     

    Sounds great. I hope that this will provide a way to modularize GC's DAG propagation graph. GC's DAG approach is powerful because of its accessibility and directness, but it also needs to be scalable. One way to deal with this is the use of 'ports' or 'gateway' nodes that have 'rules' or some code to channel the propagation. Element Sensors seem like a promising way to provide user manipulate-able 'port' nodes, to improve user interactivity.

    Breaking up DAG's mean that Mstn will need a strategy to manage the 'overall' propagation sequence. With the DAG, it is apparently a 'topological sort'. It's worth noting that Maya has dependency nodes, not all of which are DAG nodes, so it's possible, and probably desirable to go beyond 'acyclic'.

    I hope that Bentley's IP will also integrate geometric constraints solving, not just 'parametric' modeling.  CATIA and most MCAD apps already integrate constraints solving into their propagation / history based modeling.

    BTW, I think GC is more 'imperative' and 'directional' and not 'declarative' at all. GC's use of parametric math, to mesh with its propagation mechanism puts the onus on the scripter to 'imperatively' define the sequence of solving / assignments as part of its DAG. This is in contrast with the 'declarative' way that constraints equations are just 'declared' without requiring the user to define how or the 'direction' in which they are solved. I think SDRC's I-DEAS was one of the few 'variational' as opposed to 'parametric' modelers on the market.

    Design++ 's top-down approach was never really offered by any of the architectural modelers. I think this kind  of product modeling thinking, which emphasizes holistic or 'top-down' modeling. is only now emerging as BIM, I think B-Processor is interesting because of this. BA is typical or a lot of verticals that are struggling to graft on a 'top down' approach, belatedly.

    I think Design++'s KBE rule-based working could also be used in a bottom-up approach. Although, top-down tends to mirror the way a lot of AEC designers think, as they tend to progress from general to particular, as they go from Scheme Design to Detailed Design to Construction Documents...etc.

    BIM holds out a quite few challenges to GC. GC's 'parameters' math and 'update methods' are pretty much geared to geometric problems. But, to do 'real world' design / engineering, it will also need to process other kinds of 'attributes', like material types, process related info, product info etc. Stuff that is usually accessed via database links tacked on to CAD objects, hopefully structured with some form of 'knowledge representation'. GC needs to be able to operate in the context of a BIM 'attribute' database. I guess this is already in progress.

    'Implicit' as opposed to 'explicit' relationships are a reminder that there will be a lot of relationships (even without BIM) that will not be part of, or the result of, any particular 'propagation' graph. I think dealing with them will need to go beyond the GC's 'asso-para' approach. Jereon Coender's 'cross-cutting' concerns, as mentioned at SG 2010, is an example of how different disciplines / aspects will need to link to GC's propagation graph. It also highlights the fact that GC's 'direct and accessible' approach to capturing design intent can be too much 'how' and not enough 'what', on its own.  Rules-based healing? Maybe, the people behind the new Integrated Structural Model could also help?

     

  • Thanks for the tip on B-Processor,  I'll check it out.  And thanks (as always!) for the stimulating post.  Seems like there are two other topics in your post:

    One, The Bentley Architecture add-in is one particular kind of point solution in GC, but it is not the ultimate thrust of integration in GC.  The Bentley interoperability platform guides our direction here.  Broadly speaking, it outlines a means of using DGN as a repository for parametric data (rather than point solutions as the paper observes they tend to be fragile over time.) 

    Two, what you suggest with regard to characterizing the building model as 'an aggregation of spaces' reminds me of the top-down approach employed by D++.  So-called part hierarchies seem applicable to buildings in that, for instance: an occupant's use for a given reason requires a space for it, and given adjaciencies and site conditions gives rise to walls with openings. 

    (BTW, Top down seems natural enough an architectural design setting, I wonder why it didn't catch on before the more declarative, directional style of relationships we see in GC and very many other geometric systems for AEC and animation.  The answer may have more to do with the transfer of engineering technology than fitness of the approach to the domain, but likely you and others on this forum have a deeper insight into that than I do. There is something direct and accessible about the typical DAG approach that might a factor too.)