The AECOO industry has some barriers, especially related to IFC, so I decided to work on two important areas besides our startup:
IfcXtreme base concepts come from cross-platform visual programming and develop IFC entities as visual programming components and objects
The concept develops based on “end entities” which explained in IfcLite project as a question
The preliminary concept developed with Grasshopper + BHoM
I developed the idea based that complete tree, but based on end entities, for instance, IfcProject or IfcSite are end entities on the hierarchical approach.
What does it mean?
It means that I’m going to build a middle-ware which shows an easy to understand end entity like the example IfcActor, which the object on the front-end shows which data and datatype needed? And on the back-end, it converts that object to IFC-SPF or IFC-XML and or any other structured code which is standard
I put IfcOccupant on canvas and it “automatically sets datatypes, rules, functions, relationships, so on” and also I have the ability to manage them manually too.
For instance, if I add Pset_X it automatically sets relationships and everything is needed and the user doesn’t need to know relationships well
Also, it automatically and also manually can check inputs, processes, and outputs which is great for automation and control systems. Imagine you be able to sett rules object by object, for instance, say that IfcWall should give these data with these data types from these IfcXs and process these process or processes and give these outputs
This is the whole idea
(Or we put the end object and it adds all behind objects needed automatically, this is the second scenario I thought about
For instance, you put IfcProjectLibrary on canvas and it adds IfcContext, IfcObjectDefinition, and IfcRoot
But mainly I’m trying to drop IfcObjectDefinition and move relationships inside the end entities)
These days I give some positive feedback, so decided to continue
One of the must interesting was this one:
Regarding IFC I think there are only two ways out: drop it and use something more modern and flexible, or build a layer that abstracts away all the details nobody cares about.
At the end of the day, most people want to model a wall and attach properties to it. They then want to know to which room this wall belongs to, and on which floor this room is located.
As long as we are not able to provide professionals with this user experience, IFC (and BIM in general) adoption will be low or misunderstood… Just my personal opinion of course.
In this regard, building something visual like you are doing is a good step forward.
Nowadays, IFD and mainly IFC play a vital role in the OpenBIM environment all around the world, and accordingly, IfcDoc tool from buildingSMART International has become a critical tool for digital built environment industry.
But this critical tool has had a lot of issues which I just focus on some of the vitally important ones:
First of all, it is not a cross-platform tool and just works on Windows.
Secondly, the logic behind the IfcDoc tool makes the IFC schema and the IFC schema development more dependent on its data modeling tool which today has issues and bSI has started to develop it again based on UML, but in reality, UML will not solve the dependency barrier, likewise.
Thirdly, many think about parametric IFC which existing IFC development does not support.
And some other issues and obstacles ahead which led us to think and start the IfcXtreme project as an alternative to IfcDoc, which is a cross-platform visual IFD/IFC programming that revolutionizes the OpenBIM environment due to its freedoms and its ease of use which gives a gift to the end users as BIM as well as OpenBIM experts
IfcXtreme, the next generation of IfcDoc. An easy to use web-based IfcDoc
IfcLite, a lite .ifc format. The industry needs a lite format to be able to achieve a real “data/information exchange” point
ODClass, a new classification based on Industry Foundation Classes (IFC)
Globalized Reference Views - GRVs & Globalized Design Transfers - GDTs