Resurrecting annotation storage in IFC

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.

  1. 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.
  2. 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



  • 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.

  • 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?

  • Don't know if this can be useful, but i made some experiments on organizing annotations in FC Arch. I was talking about that last saturday with @Moult so perhaps can be inspiring... :)

  • 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

  • Dion, this is from STEP AP242:


  • Texture_Style_Specification

  • edited May 11

    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 :)

  • Amazing! Is the svg somewhere to have a look?

  • What am I seeing? What magic is this? O_o

  • edited May 11

    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...

  • I think I teared up a little. This is Awesome!
    Can't wait to play around with it.

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

  • 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?

  • edited May 11

    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 :)

  • @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.

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

  • 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.

  • edited May 12

    @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

  • 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!

  • edited May 12

    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.

  • 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 :)

  • 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 :)

  • edited May 12

    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 :)
    What I like about Dion is he pay attention to the points that are raised in different places

  • edited May 13

    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.

  • @aothms said:
    (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.)

    WILD idea :D

  • edited May 13

    I just wanted to share the following project
    Is a web-based realtime whiteboard.
    It relies heavily on Paper.js--a SVG toolkit.
    We use it a lot with in annotating drawings.
    Thought this tool might dovetail in some fashion in this emerging SVG workflow.

  • edited May 14

    This video caught my attention and i was thinking about 2d annotations, properties of gridlines. I find it quite remarkable these complex looking dynamo script need to be run and polute the model with text. Isn't there a better way for fellow revit bimmers? Note to myself. Can dwg do to ifc grids directly?

    Edit, so nice to have edit 1 day;-)

  • Just tried to export Grids from DWG using some software. It shows some the lines do not have gridnames What kind of object is 'ifcgrid' and why is implementated so poorly ? Or are my conclusions too fast.

  • @magicalcloud_75 in IFC, an IfcGrid does not resemble a single grid line - it resembles a group of grid lines that form a logical structural or construction group. This in my opinion and experience in projects is a valid stance.

    Inside an IfcGrid are one or more IfcGridAxis elements, each of which represent a single grid line, and will be given the name "A", "B", "01", "02" etc.

    It looks as though BIMVision does not seem to immediately distinguish this breakdown in their UI.

    I just watched that video and it looks ridiculous and downright wrong on how grids are meant to be done in both Revit and IFC.

Sign In or Register to comment.