Update: A new initiative has started to raise funds to solving this issue. Help donate to the fund here!

Right now generating drawings from Blender + IFC kinda works but it's painful and really needs a huge amount of work done to it. The end goal is for any authoring app to be able to generate construction drawings from IFC files, to the same quality and complexity of existing mature proprietary CAD and BIM applications. If this is not solved, we will not be able to replace proprietary applications. Features must include:

1. Able to run headlessly, since we want to accommodate generated drawings.
2. Vector cuts from IFC geometry (which may be one or more files, or even just shape definitions without files), agnostic of authoring tools like Blender.
3. Direct semantic (i.e. class-styled) SVG output, with indirect DXF and PDF derivative output.
4. Annotations must be stored and round-tripped within the IFC file itself
5. Associated model space view definitions must be stored within the IFC file itself, so that its annotations can be associated to the view
6. Annotations should include:
   6.1. Dimensions: linear, angular, radial, diametric - values shall be dynamic, or overridden
   6.2. Coordinates: relative levels, absolute / spot levels, ceiling levels, local / global spot coordinates
   6.3. Text: standalone text, text with a leader, text with a symbol (e.g. tags) - values shall be static, or dynamic variables, or evaluated functions (e.g. round / concatenate)
   6.4. References: section symbols, elevation symbols, detail markers - values shall reflect paperspace references
   6.5. Special: Grids, Stair or ramp arrows
   6.6: Arbitrary: arbitrary lines, and arbitrary polygons
7. Different types of sections shall follow different representation rules, based on the IFC target_view attribute (e.g. PLAN_VIEW vs SECTION_VIEW)
8. Paper space layouts
9. Fast. Users expect immediate feedback. This means:
   9.1. A real-time UI must be provided when managing drawings. It doesn't need to match the final output 1:1, but should at least provide enough user feedback such that the user isn't creating their drawing "blind". This happens on the client-side, like in Blender.
   9.2. File loading caching. File load times are slow on large projects. Only reload files if they have changed. Only load them once per session.
   9.3. OpenCascade shape caching. Creating shapes is slow. Only recreate things which have changed. Let the user specify specific shapes to recalculate. Allow element filters. 99% of the time you don't need to calculate the shape of a bathroom basin since you won't cut through it.
   9.4. Section cut wires caching. Boolean cuts are slow. Only recut if the section definition changes. That way if the user is just changing things like annotation, they don't need to regenerate the cut.
   9.5. Context-sensitive cutting. Bypass creating 3D shapes and boolean cutting if there is an annotation representation context that matches the section target view. 2D is faster than 3D.
   9.6. Bounding-box sensitive cuts. I think BrepAlgoAPI_Section gives you this for free, but I mention this because it especially applies to 2D representations. Only 2D representations (i.e. in the annotation subcontext) should be shown if its Box representation intersects the section view.
   9.7. Multicore. The multicore iterator is good for creating shapes, but multicore support needs to be added to the section cutting.
   9.8. Non-blocking processing. Is this possible? What if the file reloading, shape creation, cutting could happen in the background? File reload could detect file changes. Right now the Python implementation blocks Blender.

Apart from geometric drawing content, auxiliary content should also be able to be generated, supporting both static content and dynamic content:

1. Tabled schedules
2. Legends
3. Arbitrary text / image / content

Most of this stuff is already implemented, but badly, not user friendly, not fast enough, and not robust enough. It's implemented in cut_ifc.py and svgwriter.py. It started as a hacky script experiment and morphed into this. I didn't know C++ or OpenCascade when I wrote this, so if something looks wrong that's because it probably is.

Inputs:

1. A list of IFC files
2. A defined section plane, and optionally, if we choose to support it:
   2.1. A section box of the foreground with a distance limit
   2.2. A section box of the background
3. A list of GlobalIds of IfcElements that will be included in the drawing.
4. A list of elements to explicitly recalculate

Examples of the current abilities:

Here are some examples demonstrating what the current code is capable of generating. These are public examples, though I can say that I have privately used it to actually deliver a real commercial project to fabrication level drawings. Painfully :)

Stair (source)

Building floorplan test with annotation (source)

Hatch test (a grid of IfcBuildingElementProxy cubes with different patterns)

Development application drawing package test source

Shadow diagrams test source

Federated model plan demo source

Federated model section demo source

WIP ... will edit this issue ...