OSArch Community

Resurrecting annotation storage in IFC

  1. M by Moult on 4 May 2020, edited 25 Oct 2022 # +3 votes

    I, along with others, share the view that annotation (text, dimensions, etc) is important information and should be stored in an open-data format.

    I see two ways to do this.

    Despite the Great IFC Annotation Purge, we can still use IfcAnnotation and IfcTextLiteralWithExtent, and store annotation data in the IFC. They will be 2D objects in 3D space. FreeCAD and Blender can open these IFC files and see all of these objects in the 3D space. They can be RelAssigns to Group (to associate with a view) or assigned to Product (to associate with a product). Some custom psets can be established to allow for things like variables in annotation.

    We can try not to fight buildingSMART, and let them push IFC as a model-space only schema, and establish a new SVG-based standard for annotation. I believe this is less explored, but highly exciting. An SVG can store views, and nested SVGs store views on sheets. SVG elements can have classes and attributes that allow them to be placed in 3D space. For example, after loading an IFC into Blender or FreeCAD, you then load a particular SVG view into Blender/FreeCAD, which parses let's say <line> or <path> SVG elements, which also have a class like class="dimension" so you know it's a dimension, and origin="0,0,0" so you know where it should turn up in 3D space. Blender already implements this to some degree, in that it stores class names and object IDs to every vector object in the SVG.

    Thoughts? Ping @yorik and @theoryshaw

  2. T by theoryshaw on 4 May 2020 #

    SVG is quite attractive as there's an established pipeline of tools out there that use it.

    Although if it was all in IFC, developing tools such as diffing and merge control around one format would be a little easier, and more manageable.

    I guess I would lean a little toward SVG to play off the momentum of that standard.

    But can see arguments for both sides.

  3. Y by yorik on 4 May 2020 #

    I would vote for both! If we think right from the start to support multiple systems, it's not so much more work to support one or two, plus possible new ones in the future.

    SVG is an awesome format. But it would need an extra dose of stuff to make it all bound to corresponding objects in a model. While with IFC that is much easier..

    I wonder if there is any (old) example of 2d drawing in IFC format out there?

  4. C by carlopav on 4 May 2020 #
  5. R by ReD_CoDE on 4 May 2020 #

    I vote to both.

    FreeCAD has to immigrate to new STEP version (standard) and has to implement it, and for sure it will improve BIM/VDC industry as well

  6. R by ReD_CoDE on 5 May 2020 # +1 votes

    Dion, this is from STEP AP242:

    Annotation_Curve_Occurrence

    Annotation_Fill_Area

    Annotation_Fill_Area_Occurrence

    Annotation_Occurrence

    Annotation_Occurrence_Associativity

    Annotation_Occurrence_Relationship

    Annotation_Placeholder_Occurrence

    Annotation_Plane

    Annotation_Point_Occurrence

    Annotation_Subfigure_Occurrence

    Annotation_Symbol

    Annotation_Symbol_Occurrence

    Annotation_Text

    Annotation_Text_Character

    Annotation_Text_Occurrence

    Draughting_Annotation_Occurrence

    Draughting_Callout

    Draughting_Callout_Relationship

    Draughting_Elements

    Draughting_Model

    Draughting_Model_Item_Association

    Draughting_Model_Item_Association_With_Placeholder

    Draughting_Pre_Defined_Colour

    Draughting_Pre_Defined_Curve_Font

    Draughting_Pre_Defined_Text_Font

    Draughting_Specification_Reference

    Draughting_Subfigure_Representation

    Draughting_Symbol_Representation

    Draughting_Text_Literal_With_Delineation

    Draughting_Title

    Drawing_Definition

    Drawing_Revision

    Drawing_Revision_Sequence

    Drawing_Sheet_Layout

    Drawing_Sheet_Revision

    Drawing_Sheet_Revision_Sequence

    Drawing_Sheet_Revision_Usage

    CAx Express Schemas

  7. R by ReD_CoDE on 5 May 2020 # +1 votes

    Texture_Style_Specification

    Texture_Style_Tessellation_Specification

    Text_Font

    Text_Font_Family

    Text_Font_In_Family

    Text_Literal

    Text_Literal_With_Associated_Curves

    Text_Literal_With_Blanking_Box

    Text_Literal_With_Delineation

    Text_Literal_With_Extent

    Text_String_Representation

    Text_Style

    Text_Style_For_Defined_Font

    Text_Style_With_Box_Characteristics

    Text_Style_With_Mirror

    Text_Style_With_Spacing

  8. M by Moult on 11 May 2020, edited 11 May 2020 # +14 votes

    I've focused on annotation and documentation capabilities for the latest release of the BlenderBIM Add-on. I find that many people see Blender as purely a 3D artist tool and don't think it's possible to create construction documentation out of it. I hope to prove them wrong. I also hope to prove that this can be done natively in IFC.

    You might've noticed in the latest screenshot of the BlenderBIM Add-on release a construction documentation plan. I'll re-share it here in slightly higher-res:

    This building is a commonly used test Revit model, for need for a test model. It was then exported into IFC, and then imported into Blender. From then on, only data in the IFC model was used, and only the BlenderBIM Add-on was used to produce that documentation image. No Revit, Autodesk, or 2D touch-up programs like LibreCAD were used at all. It demonstrates:

    • Documentation in SVG output. That's right - a completely open format that anybody can view in any web browser!

    • Styles applied with CSS, including hatching, line weights, colours (not that there's much in that image), and fills

    • A section cut with vector geometry coming from IFC geometry. The geometry was processed directly from an IFC for the section but. No Blender is required - it can run headlessly.

    • Door swings geometry is actually in the IFC itself, in the Plan context, Annotation subcontext, PLAN_VIEW target view in the IFC. The section cutter recognizes it has annotation geometry, and omits rendering the 3D body representation, and substitutes it with the annotation 2D geometry.

    • All the usual annotative things you might expect - dimensions, leaders, text, symbols, etc.

    • Stair break lines are a hack. Life is hard with stairs.

    • Text annotations are added in bulk (like Revit's "tag all") with smart variables which read directly from the IFC file. Variables can be post-processed for formatting, like to round to the nearest square meter for the IfcSpace Qto Gross Area variable.

    • The view is stored as an IfcGroup in IFC. The ObjectType defines it as a plan view. This, coupled with the geometric representation context, helps store the fact that it is a 2D view.

    • All annotative elements are stored are stored as IfcAnnotation as simple 2D curves. The consuming application has to understand some conventions around the IfcAnnotation to understand that one is a dimension and the other is a leader.

    • All text elements are also stored as IfcAnnotation, but uses the IfcTextLiteralWithExtents. The with extents is a bit lame, but buildingSMART scrapped the regular text literal.

    • The SVG contains classes, at a minimum the IFC class e.g. IfcWall, and globalid-XXX and material-YYY, but can store more metadata, to allow you to semantically apply CSS styles and query your documentation for information. E.g. you can use CSS to colour all 2 hour fire rated walls red.

    So yes @theoryshaw all this annotation is indeed stored in the IFC file :)

    I also made a sample board of hatches, but hatches are now applied at run-type as SVG CSS, so the hatch pattern itself isn't actually stored in the IFC. This sample board is actually yet another IFC file :) with 1x1m cubes of IfcBuildingElementProxy with different materials set on them.

    Hope you like it :)

  9. Y by yorik on 11 May 2020 # +1 votes

    Amazing! Is the svg somewhere to have a look?

  10. B by bitacovir on 11 May 2020 # +2 votes

    What am I seeing? What magic is this? O_o

  11. B by bitacovir on 11 May 2020, edited 11 May 2020 # +1 votes

    I find that many people see Blender as purely a 3D artist tool and don't think it's possible to create construction documentation out of it. I hope to prove them wrong. I also hope to prove that this can be done natively in IFC.

    Definitively, we need a tutorial of this...

  12. T by theoryshaw on 11 May 2020 # +1 votes

    I think I teared up a little. This is Awesome!

    Can't wait to play around with it.

  13. Y by yorik on 11 May 2020 # +1 votes

    I'd be highly interested in trying to produce an IFC file form FreeCAD that is compatible with this structure...

  14. B by bitacovir on 11 May 2020 #

    These SVG files that can be opened in any web browser... it would be cool to implement web features to these files. For instance, hyper links to other SVG files or 3D views... with technical details. Is there a easy way to create interactive SVG files?

  15. Y by yorik on 11 May 2020, edited 11 May 2020 #

    Yes, same as HTML. Any element can be made clickable, and execute a piece of javascript code. There is no proper "link" element I think (inkscape "fakes" it by making texts blue and underlined then a small piece of js is executed to open the link iirc)

    You could indeed imagine a plan view where you could click to show/hide some layer... that could be cool :)

  16. B by bitacovir on 11 May 2020 #

    @yorik said:

    Yes, same as HTML. Any element can be made clickable, and execute a piece of javascript code. There is no proper "link" element I think (inkscape "fakes" it by making texts blue and underlined then a small piece of js is executed to open the link iirc)

    You could indeed imagine a plan view where you could click to show/hide some layer... that could be cool :)

    Yes. I was thinking on jump between different drawings with hyperlinks inserted on the 2D drawing. Currently, you always need to open folders or click a list of links. But create this interactive drawings with HTML will require an additional process with an html editor. It would be ideal to generate this drawings with links already incorporated from BlenderBIM or FreeCAD.

  17. M by Moult on 11 May 2020 # +2 votes

    See three attachments that show the SVG of the two drawings, and the IFC of the simpler drawing (the material sample board).

  18. M by Moult on 11 May 2020 # +1 votes

    I would additionally propose to start a thread on the buildingSMART forums demonstrating this initiative. This would help communicate the interest in resurrecting the annotation entities in IFC. That said, even if they don't listen, nothing is stopping us from building an unofficial IFC set of conventions / properties and an SVG-based standard. However, if they do listen, it may be beneficial.

  19. R by ReD_CoDE on 12 May 2020, edited 12 May 2020 #

    @Moult I'm with you. I think STEP AP242 is complete and I shared all classes/entities needed above, so what we need is to compare those entities with IFC entities and see which extra entities needed to have a complete 3D Associative Text feature

    It would be a good indicator too

    Also, STEP in the PLM area has a really good "test" framework that in the near future we can suggest bSI build such an accurate as well as a coherent framework to test Software for software certification based on

  20. Y by yorik on 12 May 2020 #

    I think ifc has diverged too much from step now, it's highly unlikely they would consider adding step entities back. I wish instead of a full "fork" they would have kept compatibility with step, make it possible to use step geometry inside ifc classes... Imagine how powerful that would be today!

  21. A by aothms on 12 May 2020, edited 12 May 2020 # +2 votes

    From the perspective of a single application it is wonderful to have access to more entities, but from the perspective of interoperability of the entire ecosystem, these underused definitions can hurt the perception of IFC in the industry and therefore adoption, as realistically only a small subset of applications will implement them and the variability of success and visualization in all the different tools suggests that the standard is broken.

    "Cleaning up", reducing complexity and choices and making things stricter in the long run will benefit us in particular as it will go hand in hand with much stricter certification requirements meaning that we as open source solutions can interoperate much more reliably with the handful of certified tools.

    Now back to this particular topic. I think there are three types of annotations:

    (a) Paper space construction drawings

    (b) Redlining and annotations of issues

    (c) Something in between, 3d descriptive model annotations

    I believe in modular software and modular standards. I would say (a) is the domain of SVG (as demonstrated by Dion, impressive screenshot!), (b) is the domain of BCF and indeed for (c) there isn't a clear candidate, but honestly I don't see it used a lot in our industry, but realize this can vary greatly between regions or disciplines.

    If we as an open source ecosystem focus on great tooling for BCF management and smart couplings between IFC and SVG that we try to standardize I think we're providing the community with a greater service than keeping everything locked up in our IFC files. An SVG they can edit in any available vector graphics editor of choice. A BCF they can exchange with all major BIM software.

  22. M by Moult on 12 May 2020 # +1 votes

    I agree with the three types of annotations. I see the first as slowly decreasing over time, and the third as slowly increasing over time (as tech like AR improves, especially). How slow, who knows? :) I also agree to leave annotation to the space of the BCF spec - in fact, the BlenderBIM Add-on has implemented all of BCF's annotative capabilities, including the obscure ones like Bitmap.

    I agree that underused definitions have definitely hurt the perception of IFC in the industry, and therefore adoption.

    However, I have a slight issue about SVG being pure "paper space". This is because I actually annotate axonometric diagrams - and for that to happen, the annotation line should be in 3D space to "intelligently" render (i.e. not hardcoded values) the spot level, survey point, dimension, etc - it won't work if the data is purely 2D. Similarly for axonometrics, the 2d lines sometimes are behind objects, and sometimes in front of objects. Also, architects do annotate 3D perspective views too, which have similar issues. I'm not sure what the "right" solution is yet, but I will explore the ability to round-trip annotation with purely SVG.

    Let's see where this takes us :)

  23. Y by yorik on 12 May 2020 #

    I also see the task of taking a plan view and placing on it dimensions, annotations, etc... as a kind of remaining of the CAD epoch... It's hard to imagine something completely automatic, where you would be spared of that annoyance, but I also like the idea to "annotate your model", where indeed a lot can happen automatically, and as much as possible 2D annotations would be provided automatically. Ex, hatch fills, room names, door/window tags, finish tags, etc... And also more and more we begin to do things like axonometric details, where annotating in the model begins to take much sense.

    Maybe there could be an interesting analogy with HTML/CSS, where you have the "definition" of elements somewhere, and the styling somewhere else.

    I'm quite amazed by how simple the annotations are in your SVG file @Moult... Didn't know you could make an SVG line look like a dimension with so little :)

  24. R by ReD_CoDE on 12 May 2020, edited 12 May 2020 #
  25. A by aothms on 13 May 2020, edited 13 May 2020 # +1 votes

    True. Paper space is not necessarily a 2D section and considering BIM, VR/AR the need for annotations will shift more and more to 3D. There is a real void here apparently in standards for 3D declarative geometries with stroke,fill,text,arrowhead kind of rendering capabilities.

    (Edit: Would be relatively easy to propose a 3D svg though. Just 3D coords everywhere (or implicit Z=0) and instead of a viewBox you have a camera matrix.)

    @Moult if you have a axonometric projection can you use the SVG matrix to encode the projection? Then at least it's possible to uncover the original unprojected length from within the SVG. Definitely will not work for perspective projections as the 4d homogeneous coord and 4x4 matrices are not part of the SVG spec.

  1. Page 1
  2. 2

Login or Register to reply.