and this is surely true. the basis imho should be the physical building in a state of extended automation.
I think the ideas I follow not only will solve many considerations also will bring new era in the industry
- Materials that are BIM-ready and globally registered once and can be used multiple times
- Objects that are BIM-ready and globally registered once and can be used multiple times
- Products that are BIM-ready and globally registered once and can be used multiple times
- Facilities that are Smart Cities-ready and globally registered once and can be used multiple times
This is the idea behind the MaterialPass, ProductPass, and FacilityPass, BIM-ready and Smart Cities-ready content that can be assembled like LEGOs and speed up the design over 100X
if it’s not automated (many parts modelled together) it won’t speed up anything…
The’re are some POCs and even some startups that prof this concepts (and claim 100X which is acceptable, like this one: https://procedural.design)
And I agree, this is why I constantly mention “I’m working on a new Design System”
The idea I suggested is far ahead of some content-based solutions like BIMobject
This brings a new era
and what timeframe we’re talkin’ 'bout?
and yes, this is the automation principle i’ve had in mind 
which app is the target creator? blenderbim?
…and the mentioned layers in the video should be the construction classification system’s hierarchic classes.
The Design System I have in mind is advanced than the presentation I shared, and layer design and procedural design is just about 20% of it
MaterialPass, ProductPass and FacilityPass projects are open source, so it’s up to all of us. The time frame could be anytime (because it’s open source)
BlenderBIM opened the door and even we shared a POC:
I’m not sure about the platform, Blender and BlenderBIM still have limitations for the idea I have in mind for “Assembly Modeling” part, and I don’t think about a platform like FreeCAD
@gester
“… the way the phyiscal building is being composed …”
In early design phase we do not know the way the physical building will be composed later.
In tender phase we often MUST NOT restrict the way the of implementation.
In tender phase we specify the wall as abstract building element with some requirements that can be implemented in different ways by the (sub-)contractor.
a) If implemented as site concrete we extrude the liquid concrete from bottom to top => vertical extrusion?
We later apply the isolation from outside and/or inside. => NO vertical extrusion !
b) If implemented as precast we extrude the liquid concrete from inside to outside and deliver the cured concrete part it to the site where it is mounted to the building. => horizontal extrusion?
Isolation can be applied at factory or at site from inside and/or outside. => how to model ?
c) If implemented as hollow wall we build a hollow room bounded by plasterboard plate => Brep ?
In tender phase we are neutral to contractors and specific implementation. We need ONE standardized way to describe the requirements for “the wall”.
We need algorithms to check for the equivalence of requirements (tender offer) and implementation (bids).
@gester
“… modelled together as a whole…”
Concrete and insulation are dividable in real life and therefore shall be divided in the model. Concrete and insulation are built at different time and therefore shall be divided in the modell.
Automation shall be done at model manipulation level (access methods operating on the model data).
well, i don’t mean if a wall is of in-situ reinforced concrete or as a precast, or even a ceramic brick but how the main components are being assembled. we surely know that interior walls come first, and the flooring layers next.
it doesn’t have anything to do with the project phase, but it has everything to do with the lod levels, and the appropriate classification level.
but surely the flexibility is an issue, too.
this is the question of easiness of modelling and automation vs the design sincerity and flexibility we’re talking about here…
…but such concepts as the viennese procedural design might be a remedium for.
Easiness of modelling and automation shall NOT be provided by oversimplified model conceptions.
Easiness of modelling and automation shall be provided by microservices that operate on the model by means of basic operations (i.e. methods, functions, procedures, … however you like to call it …).
Model conceptions shall be appropriate to help solving the considered problems . This can be interpreted extensively.
Misguided by the assumption that simple model conceptions simplify the considered problems we typically end up with oversimplified model conceptions that are inadequate for effective problem solving.
The basis for model conception should be the physical building (in very detail and close to reality) instead of easiness and automation. The microservices will provide easy, user-friendly automation to hide the model complexity from the users (architects, structural engineers, …), especially for common planning steps.
nobody said this that’s why we look here for solutions
this was my standpoint, too 
I think anything you mention would happen in the project I do
High level of detail (LoD) model based on the right geometry paradigm(s) that modeled once and accepted globally, and can have some geometry representations too which represent the main geometry (AP 422 has something like this I think) inside the Material/Object/Product Passport and are natural in different worlds GIS, BIM, PLM, VFX, XR, … and appropriate data/information/knowledge can be linked to these materials and geometries based on use-cases
is it supposed to be a plugin for existing cad/bim applications, or a standalone product?
I disclaim modelling together as a whole what is not a whole in accordance with empirical realism.
I disclaim modelling practices in discrepancy to reality that make life easier for software developers at the cost of having models that are not in accordance with empirical realism.
Modelling of windows and doors with automatic component wrappings and splays is the duty of the microservices that are operating on the realistic model. The model itself shall be based on a precise model conception that are consistent with empirical realism.
Summarized:
I welcome operations for automatic component wrappings and splays.
I refuse model conception that imposes compounds that are in contrast to empirical realism (e.g. for facultative insulation that is mounted to a concrete wall at a different time period)
1 Like
I refuse software models that are inconsistent to empirical realism (e.g. in contradiction to the way the physical insulation is being set up)
Model conceptions need to abstract from reality. This can be done by omitting details or by simplified representation of details. But I refuse model conceptions that prescribe wrong details (e.g. 45 degrees insulation cut).
I welcome model conceptions that
a) omit unknownd details (e.g. the insulation cut angle)
or
b) request user specification of detail (e.g. the insulation cut angle)
or
c) use common detail as default (e.g. a common insulation cut angle) and allow for user intervention to deviate from default
I think omiting details is not a good idea
Indeed building “patterns” for walls, floors, roofs, etc that are so close to their reality is the answer
How many different walls we have in the world? Just we need build their “pattern” then in software just you select the pattern you want and draw your wall
Also, these patterns have the ability to add or remove their “layers” and “details” too
There’s a long time I know its name “ATOMIC DESIGN”
One obvious example for omitting details in structural engineering is the inner structure of concrete. We typically omit the conglomerate details and model the concrete as continuum. Sometimes we omit details of reinforcement and model the combination of concrete and reinforcement as continuum with specific mechanical properties.
This is abstraction but still somehow consistent with reality.
45 degree insulation cut typically is not consistent with reality, is it?
It’s not
I think what we need is just two things (which some software today have both, for instance Dassault Systemes software):
- STEP AP 242
- Modelica
Then we will be so close to reality “if we add Atomic Design” to the (digital) built environment industry too (which this part is new and I’m working on it)
let’s be realistic (and i’m an advocate of the designers, mostly architects here - i’m one myself): architects won’t buy a software product that doesn’t provide that kind of time-saving automation
just forget it.
we need solutions that provide both.