A couple of months ago I wrote a complete post on LinkedIn about “Data/Information Loss Rate” and explained current conditions in the industry when firms choose scenarios this way:
If two software have an “official” plugin choose this scenario
If not, choose IFC
If not, choose an “inofficial” plugin (plugins from third-parties)
If not export/import through another file format
So, the majority of times IFC is the second choice, and do you know it’s obvious
Also, traditionally countries and firms see IFC as archive solution
So, I don’t know what’s bSI’s plan, but personally I want (or try) to be optimistic to IFC’s future
@Hans_Lammerts Great, so yet another geometry kernel solution being pimped to the marketplace. And add yet another point of pain.
Are you, or anyone, proposing that bSI force all software vendors to abandon their core geometry kernel technologies and just use the same one? The last guy who proposed that got laughed out of the room and never showed up for another event.
These issues are well-known to many who have been engaged for some time. Yet, the industry still seems to make it work. Over the last 10 years, I have seen more success stories in the use of IFC in projects large and small, especially across Europe, grow geometrically, if not exponentailly, in spite of all the naysayers.
That isn’t to say that everyhting is now perfect or can’t be improved, but it doesn’t mean that the house is on fire because someone lit a fire in the fireplace instead of turning on the central heating system (forced-air, electric radiant, steam radiant… your choice ;-})> ) or lit a candle for light instead of flipping a switch.
Progress takes time and attention. Patience, respect, and constructive contribution are virtues sorely needed. Lamenting gets you no where.
Kernels and IFC don’t really have to not bite each other, do they? I see only positive things. Newcomers like C3D bring innovation and COMPETITION.i I am quite sure it has been a while since ‘my kernel’ had some serious competion. It is founded in history about a lazy company. (Lamenting is this Part, not IFC!) And i don’t understand the laugh about really. Just trying to find more and better suitable ways to get work done. With IFC.
But it might be we are getting further away from the topic. I am not a an expert in the ins and out of IFC. Far from. But to me IFC seems so flexible in many ways (?). IFC supposed to be a format to make bim happen across platforms. However, when it comes to geometrical flavors it is a rigid (?) And therefore some software with other kernels will not be able to deal with IFC. Right , not right. Just learning here…
Another geometry kernel solution competing on the marketplace. One man’s pleasure is another man’s pain.
I take the risk to get laughed out and to become proscribed:
No, I do NOT propse that bSI forces all software vendors to abandon their core geometry kernel technologies and just use the same one (the same implementation).
But I expect that bS acts unbiased and neutral.
I expect that bS standardizes the interfaces between applications and (distributed) CDEs (e.g. by an open IFC-API).
I expect that bS standardizes in a way that an ordinary cuboid wall will end up in one standardized representation, independent from software implementation.
If there is good reason from construction point of view to have different representations in different situations then the standard shall provide unambiguous decision rules.
“These issues are well-known to many who have been engaged for some time …”
I thank you and the other experts for providing valuable feedback to lateral thinkers instead of laughing them out.
I value the big success that has been achieved in the past.
I see the need for even more standardization far beyond DTV data structures. I wish that bS drives this future progress in an unbiased and neutral way.
“Progress takes time and attention. Patience, respect, and constructive contribution are virtues sorely needed.”
Yes, I agree.
But “lamenting” I see different: Lamenting is base and impulse for further improvements and progress.
Whitewashing everything and laughing out critical voices gets us no where.
Again, respect for the achievements of the bS community!
@tauscher
Thx for clarification that DTV is not meant to guarantee lossless roundtrips.
DTV is a concept that is already available to the market.
“Lossless roundtrip” and “conservative IFC processing” are long-term ideas/concepts (around 10 years to market) that need further discussion and refinement. It is related to CDE concepts with “partial model exchange from a server” (IfcStateEnum).
But definitiely this are other topics:
About the phrase “all software vendors to abandon their core geometry kernel technologies”
In infra domain design gets to be done with numerous software with even more different kernels. Autodesk alone has 4 different software packages (kernels!) bundled together. To design a bridge one needs a combination of Civil3d / Revit / infraworks and Inventor. What’s to abandon?? Somehow they manage to tie them together from a geometic point of view.
What i am saying is, there is no ONE vendor ONE kernel technology. IFC should be able to do all (or vice versa) And about “abandoning kernels”. This will only be done for marketing commercial reasosn. Not for technical seasons. My $
I just wanted to reply to this thread to say that @Herb’s suggestion of conservative IFC processing / incremental IFC writing is an excellent solution to the “which representation lets me do what I want” problem (and even more), as it:
Prevents huge data loss, which is what happens now for every IFC tool (half of the reason is because each tool has its own geometry kernel, and pre and post processor for IFC geometry - such is the reality)
Does not nominate any preferred representation, so remains neutral and lets the user decide what is appropriate. This is a much better solution than the current prescriptive DTV MVD which no matter the best intentions, are not too relevant in practice.
Makes the certification process easier, as vendors do not need to implement or support the full gamut of IFC representations
Increases competition and innovation in the market as tools can specialise on modifying and authoring smaller aspects of the IFC schema
Effectively modularises a lot of the IFC schema, if applied not just to representations but to other isolated subclasses of the IFC element tree (documents, classifications, structural analysis, etc). There is no need for a massive rehaul as envisioned by @berlotti.
The DTV MVD becomes obsolete. Users can instead specify different representation exchange requirements for different objects. For example, we may specify CSG for all steelwork at fabrication stage, meshes for all vegetation and concept LOD objects, and point clouds for scans, extruded solid for pipes, swept disks for rebar … etc. In fact, this is already happening in practice: Solibri’s unit tests, Bond Bryan’s test suites, @jonm’s mvdXML test suites, BIMTester’s test suites, BIMServer’s validator tool, have all arrived at the same conceptual solution simultaneously.
I have said it before in another thread, but I believe implementing this is a high priority for all vendors to improve the quality and robustness of IFC transfer. I will prioritise it myself for BlenderBIM.
@Herb, I cannot add more than one “like” to your post, but if I could, I would.
Personally, I’ve waited for IDM Toolkit and also “hopefully” a “FEDERATED” CDE (I have something far ahead than even federated CDE, but time is needed)
Then we can talk about more about MVDs
Today talking about solutions that most of them were/are good (and even not good) before ISO 19650 is just wasting the time
Wait to see what’re those 20 MVDs which two of them nominated but need improvements and then we can talk about it
The DT MVD is meant to “transfer (pass on)” a design from one software to another one. If you want to do 100% full round tripping (e.g. have complete same editability between source and target) you are best to use the same software. That is a simple solution. You cannot expect Software A > MVD DTV > Software B > MVD DTV > Software A without any impact (although the suggestion from @Herb is appealing - that is: retaining as-is what you do not edit).
More than one way to geometrically describe an object
There is no single agreed way to describe the geometry of a wall. I immediately see several options:
horizontally swept profile along a path (e.g. Complex Profile in ARCHICAD)
side profile (sketch) with extrusion (e.g. in Revit)
primitive box and Boolean Set operations (e.g. most CAD software)
series of flat faces enclosing a volume (e.g. Mesh modellers, such as Blender or SketchUp)
complex NURBS-based enclosures for organic shapes (e.g. Rhino)
SubD Mesh models for an alternative approach to create organic shapes (e.g. Mesh modellers such as Blender or 3ds Max)
Point cloud might even be another alternative
Modifiers
And you can then still combine this with all kinds of modifiers: voids, trims, cuts against other objects. Looking at the SEO (Solid Element Operations) in ARCHICAD also introduces some nice variants on Union, Subtract and Intersect which don’t fit regular CSG operations (e.g. subtract with upwards extrusion).
Semantic or geometric focus
Initially, Revit and ARCHICAD as “semantic BIM modellers” provided basic commands to model walls and called it the wall tool. More “Geometric modellers”, such as Rhino or SketchUp or BricsCAD give you the freedom to apply any sort of geometry you need. Gradually, the two approaches are getting closer to each other, where the user (designer) chooses a suitable geometrical modelling method which best represents the object at hand and then attaches meaning to it by classifying it as an “IfcWall”.
There is no single way to model a wall in any particular software these days. Why would you expect that the DTV would describe a single way to say what the geometry of a wall should be?
To me, it would be to describe the geometry as close as possible to the modelling method in the source application. If the source is a mesh, transfer a mesh (Tesselated BREP).
This is the best choice, however, needs IFC supports all paradigms other software support, which today IFC (IFC4) has a lot of improvements related to LoD (or LOD)
So, I think it’s better we all see in which areas IFC still needs more improvements and add more classes (or even reduce or change some parts, sometimes the flexibility IFC suggests is not good and causes different implementations)
And DTV has to be flexible then and CSG “alone” is not suitable as @Moult mentioned and @Herb came with an interesting idea
Also, if some think it’s possible to exchange geometries/topologies between different paradigms should find the best ways/methods (algorithms)
Also, if we see, today some companies have started to join their software to each other, like Revit and Rhino, so this means that soon the majority of software will support or have to support different paradigms (the idea @Herb mentioned)
I take the stimulus from @ReD_CoDE respective “federated CDE” to discuss such long-term concepts within an other topic as this is different to this topic about “DTV” (about state of the art huge BIM L2 container transfer)
How is the selection of the export representation organized in the mentioned “advanced software” ?
1.1 export representation equal to import representation ?
1.2 export representation as standardized for the particular use-case ?
1.3 export representation in discretion of the building domain expert ?
1.4 export representation in discretion of the software-vendor ?
Today frequently we see software-vendors ruling our world -> 1.4
In year 2030 I would like to see subsidiary decisions 1.1 -> 1.2 -> 1.3
1.1 equal to import representation for elements without intentional design change (conservative processing)
1.2 as standardized for the particular use-case
… for new elements (no previous import)
… and for elements with design change that affects the use-case and subsequently affects the standardized use-case specific representation
1.3 in discretion of the building domain expert for ambiguous standard representations (user selects from ambiguous standard representations list)
… and for missing standard representation
… and for special use-cases where deviation from the standard representation is arguable
Normally the AECOO industry (tha (Digital) Built Environment industry) is a decade behind the other industries, so, for sure, other industries solved the challenges today we struggling with them
Advanced PLM software use a hybrid approach, which Solid and Surface modeling and other modeling paradigms combined
I don’t have enough knowledge and experience in PLM/PIM to answer the question you asked, but I’m sure that they solved, or somewhat solved this challenge, and just I should research to find the answer
I strongly believe that best practices from PLM and VFX industries will “revolutionize” the BIM industry
Dear friends, I know that maybe some friends says choosing one geometric representation paradigm is not a good idea, but
If you had the chance to choose just one paradigm for geometric presentation and representation which can support GIS, BIM, and PLM, what was your choice? and why? It was NURBS?
