Sharing core functionality instead of disparate implementations across Blender addons
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:
- 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.