Sharing core functionality instead of disparate implementations across Blender addons

edited June 7 in General

The suggestion has been raised to collaborate on some core features between various Blender addons. @Moult asked me to make a thread here as a means to facilitate inclusive discussion. I am new to this area and not an expert, so feel free to jump in and correct any misconceptions.

Areas which seem to be at the core of an architectural offering but have been approached by various addons in different ways to date include:

  • Dimensioning
  • Annotations
  • Section views
  • Drawings list and output
  • Hatching for materials indication

All of these areas have partial implementations already, enough to achieve the basics, but are not yet fully polished.

From a fundamental programming perspective it would be good to:

  • Verify that it is easy and feasible to share data between addons
  • Review and potentially alter or expand the list of shared areas above
  • Decide on how to solve those core problems in such a way as to be useful to current and future addons without limiting the scope of the interface provided
  • Attempt to improve current work with the necessary changes.

I will now make some brief comments on each specific area, so that others can continue the discussion.

Dimensioning of some sort is implemented in at least @kcress's MeasureIt-ARCH (a fork of MeasureIt), s-leger's ArchiPack and CAD Transform, and @Moult's BlenderBIM. From a user perspective, some current implementation differences are:
* Whether and how dimensions are stored
* Font typeface and size configurability
* Dimensioning style and/or widget selection
I have not reviewed ArchiPack in detail but believe its automated on-screen dimensioning may be the most mature judging from demo videos. I have also not reviewed closed source CAD packages to understand what the closed source world expects. However, I have done a lot of manual dimensioning recently and I think it's fair to say that until this is sorted out, the open source offering in this space is weak at best. Therefore, it is in everyone's interest to get this resolved. BlenderBIM / @Moult's approach is apparently to associate SVG arrow forms with the output file, and to drop them in as part of the output SVG. This works well and is incredibly efficient for SVG file size as well as configurability. However, it does not appear to resolve the on screen display issue and I recently discovered a crash with the code, so it's fair to say this is maybe not yet well tested. MeasureIt-ARCH / @kcress's approach is apparently to focus explicitly on this area, and the implementation is increasingly attractive and well-featured, but output has never been discussed so that screenshots/renderings as bitmap output were the only supported mechanism, and SVG output is not yet supported. He has however begun a proof of concept to port this over from @Moult's work. Annotations are quite similar, likewise included in at least BlenderBIM and MeasureIt-ARCH, but perhaps neither could be considered mature implementations.

Section views are another core area without a standard approach. While there are ways to achieve this manually, for nontrivial projects with multiple sections and numerous elements it is tedious to do so and a quick-switch method between stored section views is really a core requirement. Currently it seems that @Moult's BlenderBIM module is the most advanced implementation, however I have not yet personally tested it. Conceptually, all sorts of Blender users may like sectioning, not just people who wish to produce architectural or construction related documentation. Currently there seems to be some indication that Blender's camera-for-everything approach (default in the 3D programming world) is seeing some push-back or is not quite scratching everyone's itch, with Blender addons such Stored Views as being presumably popular and mature enough to obtain official status. Personally, with only limited Blender experience I often find myself changing the visibility of various object collections in order to switch between intended views. This might be, for example, showing a current vs. a proposed building state, or showing a view from a different angle without intermediary objects (foliage, figures, furniture, etc.). Therefore, I would potentially suggest that some way of (re)storing cameras while simultaneously performing arbitrary additional functions (altering object visibility, enabling a cutaway to produce a section view, altering the time of day or day of year settings in the 'Lighting: Sun Position' addon to effect a different time of day/year view, etc.) may be the most practical way forward. Developers with actual experience writing addons and more Blender experience than me would be better placed to evaluate the feasibility of this suggestion. Perhaps this could be raised with other parts of the Blender community or core developers.

Drawings list and output. This links strongly to the prior comments on section views, but is broader in scope. For example, conventionally drawings tend to have both titles ("West Elevation", "Ground Floor Plan") and numbers or codes ("D", "12", "B-3", etc.). At present, drawings are orthographic cameras and thus require an associated camera object. I suppose section views also have associated planes. Thus, in reality a drawings list is a list that should exist outside of camera objects, as a separate entity, so that metadata such as title, code, and associated objects may be stored. @kcress has also done a camera-specific-resolution addon, which might be better termed drawing specific resolution. Anyway, it seems this is quite fundamental in using Blender to generate any sort of output, not just drawings, for example video (eg. a house walkthrough) and various materials lists (commonly this would include a door schedule, window schedule in built architecture, a vegetation list for landscaping, etc.), which also share the need for titles and potentially codes. Therefore, I think a common structure could be established for this purpose that facilitates future use and considers reasonably the potential for use outside of merely architectural documentation. Perhaps this could be raised with other parts of the Blender community or core developers. (Some existing notes re. relative placement of multiple views on a drawing, proposal for automatically naming drawings using data from Sun Position addon, etc.)

Hatching for materials indication is practically significant in having drawings taken seriously and interpreted accurately by the relevant audiences. @Moult has implemented an awesome SVG-based system which seems to work well in demo, although I have not personally tested it yet. We would perhaps do well as a community to produce a serious library of such patterns and provide them with an option for users to select which rendering methodology they would prefer from any of various standards in use around the world. There is also the question of relative scale - I imagine this is specified precisely by standards bodies in some cases. Can anyone provide links to their locally applicable standards?

In closing just a quick note that perhaps materials schedules and hatching-related materials specification could be one of the 'gateway drug' methods to get people in to Blender and BIM, since I imagine that generating an SVG or CSV should be relatively trivial and far faster/cheaper than closed source options.



  • @kcress and @globalcitizen and @stephen_l can we organise a quick video call to go through our implementations to see how they can be combined or made compatible with one another? Both @globalcitizen and I are in the Sydney Australia timezones. What timezone are you guys in?

  • Early morning works well for me, say 6-8AM Sydney time.

  • edited June 8

    I'm EST here in Toronto Canada, around 6-8AM Sydney time works well for me as that's 4-6PM here!
    I'm generally free later than that as well, but I do have a meeting at 7:30 EST on the 9th this week though.

  • 8am Sydney time is good for me too. How about this Friday 8am, Sydney time, so Thursday 6pm Toronto, at ?

  • edited June 8

    Can't really start at 8AM as that's peak child-before-school... 7AM (max 1 hr available) or 7:30AM (max 30 min) OK?

  • I can do 7am.

  • OK great ... @kcress seems OK with that, @stephen_l ?

  • edited June 8

    Hi no problem for me,
    8AM Sydney time means 0h00 Swiss time and it is ok for me.
    There are 2 distinct things, on screen "manipulators" and dimension lines + text.


    As for implementation, in archipack dimensions rely on "measurable" concept.
    A measurable object provide some kind of hook to own points, manipulators with small "+" to add measured point to a dimension. Dimension object rely on those hooks to retrieve measured points. So any update of measurable will also update dimension line. Dimensions are curves+text so direct export to .svg / .dxf is possible.

    Floor plan

    Until now archipack entity build 2d lines for .svg export on the fly at export time, as this solve the synchronization issue of lines and 3d entity by design - no need to update lines when 3d model change.
    Exported region is defined by a "canvas" entity (a representation of sheet of paper boundary)

    Side view / cut

    There is a limited "section" object able to build static "cut" as lines, but it is nearly impossible to add background objects as lines using python, as it require pretty complex processing, we all encounter that same issue.
    Have made some investigations using "potrace", one of the vectorization method of inkscape, but without much luck. Noted some precision issues with such kind of methods.

  • edited June 8

    Hang on @stephen_l we were suggesting 7AM Sydney time Friday morning, so 23:00 Thursday night Swiss time. Is that OK?

    Quick extra comment for context, I just saw a link posted by @ReD_CoDE regarding Aras Innovator and the Wikipedia page for PMI which specifically discusses linking views to model state as an existing feature in commercial CAM software: PMI items are often organized within annotation views. Annotation views typically view including camera/view position, selected and also the particular state of the assembly (visibility, rendering mode, sometime even position of each element of the assembly). This provides additional evidence supporting the proposal I made regarding camera related state recall being a desirable feature for people in both architecture and other professional domains that we might consider in conjunction with Blender core developers.

  • edited June 8

    Yes it is OK.
    As for blender core developers, looks like blender's chairman is a bit reluctant to the idea of cad in blender.

    Ton @ton
    isn't FreeCAD offering this suffiiciently?
    of course, anything that works for addons is fine. but there's a grey area where it becomes interesting for CAD devs more than for Blender


  • blender's chairman is a bit reluctant to the idea of cad in blender.

    OK, there are still ways to get that done. We could, for example, just take care to present it as an improvement to the existing official 'stored views' addon then. ;)

  • Using "native" add-on is possible, but limited by blender release cycle. This may be an issue with LTS and bleeding edge being not stable enough in the between.

  • edited June 8

    Before the meeting, could someone else who is an existing Blender developer please double check any limitations or gotchas on data sharing between add-ons in Blender? For example:

    • are all inputs to a foreign add-on detectable from a different add-on?
    • is the installed version of a foreign add-on detectable?
    • is it possible to detect an installed but not enabled add-on and request the user to enable it?

    This would help to solve the first point Verify that it is easy and feasible to share data between addons.

  • is the installed version of a foreign add-on detectable?
    yes, but require import of bl_info
    is it possible to detect an installed but not enabled module and request the user to enable it?
    yes, it is even possible to enable it when present.
    At this time archipack use blenderbim addon for ifc export when present, even when not enabled.

  • perhaps materials schedules and hatching-related materials specification could be one of the 'gateway drug' methods to get people in to Blender and BIM, since I imagine that generating an SVG or CSV should be relatively trivial and far faster/cheaper than closed source options.

    More evidence this is the case: recent tutorial shared on generating XLS with IfcOpenShell in Python.

  • @stephen_l @kcress @Moult Reminder, video meeting in about 15 hours.

  • My summary of meeting, I left a bit before the end.

    Views and sheets

    • BlenderBIM will remove views and sheets code, instead this will move to and use exclusively MeasureIt-ARCH

      • MeasureIt-ARCH has this week implemented an improved UI for views and sheets already
      • List of views and sheets and annotations will be kept "vendor agnostic" (ie. non Blender specific) for forward-looking IFC and FreeCAD interoperability
      • Blender's built-in View Layers will be used to associate object visibility within views
    • BlenderBIM (currently stored in IFC as a curve object) will remove all annotation code, instead this will move to @kress 's MeasureIt-ARCH and expose a start and an end point and will be possible to store outside of Blender

      • Suggestion is to add CSS class in an output SVG, with some option to re-import annotations.

    SVG output

    • To be maintained via BlenderBIM.

      • SVG CSS styling is the preferred solution for output plan drawing detail
    • @Moult explained why cutting from Blender to do SVG output is hard.

      • Currently BlenderBIM's SVG output doesn't use from Blender, it cuts vectors from mesh generated from the IFC which is exported from Blender and has the Blender render behind.
      • One point is that construction vs. services drawings have different conventions including visibility of certain objects.
    • Some discussion of alternative approaches with vector/raster hybrid (image tracing), pre OpenGL systems, etc.

    • IFC includes:

      • the ability to store a 2D design of how to diagramatically represent something like a door. @Moult has code that runs this already. @kcress will not likely bother with this, but @stephen_l 's Archipack has this already.
      • SVG 'def' is currently used by @Moult's BlenderBIM to repeat these throughout the SVG, which is an elegant approach
      • Grid lines as IFC objects in 3D space
    • OpenGost font is used by BlenderBIM and recommended (traditional Autocad uses Gost)


    • @stephen_l points out that dimensions cannot be treated in an over-simplified fashion. He explained currently Archipack uses a measurable object property to determine what is measurable and then associates measurements with those points. Concerns around sum lines / parametrics. He has the most experience with this as he has a user base making requests in this space.
  • Things we discussed after @globalcitizen left:

    • Not all annotations will be smart and parametric - we will retain a way to have "dumb" 2D objects on a drawing in all our implementations.
    • We will distribute a bundled version / one-click setup that provides a full installation of BlenderBIM Addon + MeasureIt-ARCH + ArchiPack (Free Version) + CAD Transform. Potentially Also including BlenderGIS (assuming we solve issues with their libgeos). If it is one-click, there will a progress bar of some kind. The installer is standalone and can be bundled with each individual add-on which can then be used to grab all other add-ons.
    • @stephen_l will still distribute his paid version of Archipack how he sees fit.
    • Temporary section cutaway feature will be removed from the BlenderBIM Add-on and moved to MeasureIt-ARCH.
  • Sounds great guys!

    A few questions:

    • What is the combined bundle going to be called? Lighthearted suggestions:

      • Blabberwocky = Open Blender Architecture Bundle: Brilliant Everlasting Wicked Opensource Construction Knowhow Yurtbuilder (see urban dictionary)
      • OpenBlax = Open Blender Architecture 'X' (where 'x' means anything and everything, reflecting the bundleness)
    • Where will it be distributed?

      • Suggestion: Dedicated Github repo
    • How will the one-click bundle be combined?

      • Suggestion: CI/CD system with an auto-rebuild. Two versions could be maintained: bleeding edge version (every addon latest 'master') and a stable version (every project 'latest release zipfile'). Can help out with the CI/CD system here if necessary.
  • Every project keep her own repo, no need for auto-rebuild infrastructure at bundle level, the one click bundle setup will be a generic "on demand" auto-updater able to download, setup, revert to saved local version.
    Bundle setup / updater will be a stand alone add-on, so code only is written once for all.
    It still is possible to setup a single add-on stand alone, and get the updater at any time to either setup all at once or upgrade to full fledged bundle whatever are installed add-on.

  • As for where it is distributed, OSArch has a Gitlab account where we can probably put it there, as it is shared by all projects. Everybody can have admin access to it :)

  • For the names, would suggest some kind of things with strong identity like
    B-osarch standing for osarch initiative for blender
    F-osarch same for freeCad and so on.

    I also would like to rise another concern about overall initiative, regarding onboarding, documentation and support.
    At some point most "arch people" are somewhat reluctant to technology things, so it is vital to provide a clear, complete documentation, and the easyest possible onboarding experience.
    We also must be able to provide a decent level of support professionals users may expect, possibly commercial support so it remains sustainable.

  • What? Conservative names?

  • don't forget to install Sverchok

  • @nikitron yes :) Let's totally do that too! Can you think of any complications or is it straightforward?

  • @stephen_l - I don't think we agreed on who would build this "add-on to install add-ons", but you seemed quite experienced in this, would it be possible for you to build this?

    @kcress - how close are you to providing a method that I can call to get the coordinates of start/end dimensions? I think once that function is available, most of my code can be ripped out.

  • Will take a closer look at "Merlin's" last year GSOC work as he should handle such thing and probably more (asset download), alternative is a huge refactor of CGCookie updater to handle multiple add-ons at once.

  • About import across add-ons

    Make dynamic import at run time so cross import will not end up in dependency hell

    def xxx(y):
        # inside the body of your func
        from addon_name.file_name import class_or_function
    def include_blenderbim():
            from blenderbim.bim.export_ifc import (
  "found blenderBIM addon")
           HAS_BLENDERBIM = True
        except ImportError as ex:
  "BlenderBIM addon not found %s" % ex)
            print("BlenderBIM addon not found %s" % ex) 
  • @Moult I should be able to have a function like that up and running by this weekend.

  • edited June 18

    @Moult whats the best output/return type for your purposes? I could write this as an operator that generates curve objects for each dimension, similar to what BlenderBIM does now, or it could just be a simple function that returns a list of co-ordinate pairs? Whichever works best for you!

Sign In or Register to comment.