Auto-generating drawings

[brunopostle]

I'm working on some code to auto-generate BlenderBIM drawings for an IFC file, and have some questions..

I'm iterating through all the buildings, finding each bounding box and creating a plan 'drawing' for each storey, then adding these plans to a sheet (one sheet per building). This is a project with 32 buildings:

In BlenderBIM, activating a drawing and clicking 'create_drawing' creates assets and cache subfolders, copies over all the assets, generates SVG, and generally does everything you get if you had clicked 'add_drawing' in BlenderBIM to create the drawing - ok.

..but doing the same for sheets doesn't work the same way, clicking 'open_sheet_layout' complains that SVG files are missing. It seems that generating the SVG for sheets only happens when you 'add_sheet' in the UI. If this is an oversight I'll try and fix it (but I'm still very confused by the bbim code structure, this may take a while). Ultimately a user should be able to receive a bare IFC with drawings and sheets configured and be able to generate all those sheets.

The sheeter module places all drawings at a hard-coded 30,30 (millimetres?) position. Is the plan to eventually have some tool in BlenderBIM to control this? or is this something where positioning will always be done in Inkscape? An intermediate solution would be for locations to be a property of the drawing Document Reference which is respected when the sheet is generated?

I'd like to be able to label all the rooms. In BlenderBIM you have to have an active 'drawing' in order to add annotations. Is this a hard limitation? are all printable annotations necessarily associated with a drawing?

The Bulk Tag function is nice, is there any reason why the Literal defaults to the string TEXT and not to {{Name}}?

[brunopostle]

Here's a work in progress script, it creates plans (with labelled spaces) and a north elevation for every building in the IFC file.
endrawingify.py.txt

[Moult]

Yes it's an oversight and there are currently a lot of assumptions in the code e.g. that you've first created the drawing before adding to the sheet or the SVGs exist etc. It's definitely very messy and that's because it grew from a messy prototype but hopefully the mess is slowly being cleaned up as we figure out what approaches work and what doesn't.

The hardcoded 30,30 is definitely "just get it working" code. Huge improvements can be made here such as integrating with Inkscape through an Inkscape plugin, or integration with the upcoming web UI (hopefully from GSoC) which will allow you to do simple page layouting from the web, etc.

Annotations do not need to be associated with a drawing, no. But we probably haven't done much in the UI to make it friendly to add annotations outside drawings.

The intended workflow for the bulk tag is that you'd ideally tag using an annotation type (which would then enforce the {{foo}} content).

[brunopostle]

Thanks, have a better idea what is going on now.

It's a shame blender doesn't allow SVG textures. BlenderBIM could conjure up single-face mesh proxies for each of the SVG fragments and allow the user to arrange the sheet in the 3d viewport (or even all the sheets at the same time in a single workspace)

[aothms]

Could you use imagemagick/inkscape to convert the svgs to pngs and just transparently cache then? Also I guess there is also the UV/image editor which is more 2d?

[brunopostle]

IfcDocumentInformationRelationship seems like a likely candidate to store drawing placements in sheets, attributes could be:

Name: "SVG placement"
Description: "30 30 pixel"
RelationshipType: "sub-document"

A drawback is that IfcDocumentInformationRelationship seems to be strictly hierarchical, a document can have multiple attached documents, but an attached document can only be attached once. Currently it is possible to have a drawing attached to multiple sheets.

[theoryshaw]

l'm learning.

but an attached document can only be attached once.

How can you tell that from the schema documentation?

[brunopostle]

On the page for IfcDocumentInformation, the IsPointedTo virtual attribute can list any number of documents, but the IsPointer virtual attribute can only list zero or one references.

The IfcDocumentInformationRelationship RelatingDocument and RelatedDocuments attributes say the same thing.

[brunopostle]

..it looks like the sheet can have a single IfcDocumentInformationRelationship with a list of multiple drawings, but it can't have multiple IfcDocumentInformationRelationship, so kind-of useless unless we reverse the meaning, which is a little bit ugly.

[aothms]

I guess the alternative would be to build this out using objects that inherit from object definition (which maybe would be preferably anyway, for ownerhistory et al). So maybe you could have something like IfcAnnotations/IfcVirtualElement as sheets and IfcAnnotations/IfcVirtualElement as drawings, and IfcRelAssignsToProduct relationships between them. You can then still use IfcRelAssociatesDocument to link from the annotations to actual documents. Also ugly.

[brunopostle]

I have a tool that auto-generates GA drawings. This project has 219 drawings on 32 sheets and it seems to work ok:

Though to do this I'm currently stuffing the drawing position on the sheet into a pset attached to the IfcAnnotation for the drawing. This is wrong since the reference to the drawing in the sheet is an IfcDocumentReference, and the drawing might appear in multiple positions on different sheets with multiple IfcDocumentReference.

The problem is that IfcDocumentReference doesn't have any space to store this position info: Identification, Name and Description are already occupied by this use-case. My only idea so far is to attach it in the Location URI attribute, ie. currently this IfcDocumentReference looks something like this:

#259053=IFCDOCUMENTREFERENCE('drawings/Building plot-22 NORTH.svg','4',$,'DRAWING',#258733);

The location could be attached as a query string to the URI:

#259053=IFCDOCUMENTREFERENCE('drawings/Building plot-22 NORTH.svg?x=30;y=330','4',$,'DRAWING',#258733);

[brunopostle]

This could get more difficult, axonometric drawings like this would need non-uniform scaling and rotation as well as position: